Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

When Should an Analyst Suggest Using Queues in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:43:00 GMT

One of the most underrated skills for a business or system analyst in integration projects is knowing when to recommend a message queue — tools like RabbitMQ, Kafka, or Azure Service Bus.

Let’s be honest: not every integration needs one. But when it does, queues can save your system from chaos.

What Queues Actually Solve

Message queues are not just “another tech buzzword.”
They handle asynchronous communication — meaning systems don’t have to wait for each other to respond.

Example:
Instead of sending an invoice from System A and waiting for System B to confirm,
System A drops the invoice into a queue.
System B picks it up when it’s ready.

Benefits:

Smooth data flow even if one system is slow or offline
Built-in retry and error handling
Better scalability — handle thousands of messages per second
Natural decoupling between systems (less spaghetti logic)

When Analysts Should Recommend Queues
You don’t need a queue for every integration. But consider it when you see these signs:

High volume of transactions — more than a few thousand per hour.
Unstable or external systems — APIs that sometimes fail or have latency issues.
Different processing speeds — one system sends faster than another can receive.
Business-critical data — where you can’t risk data loss or duplication.
Complex workflows — where multiple consumers (systems) need the same event.

When Not to Use Queues

For real-time user interactions (e.g., “show me the balance now”) — queues add delay.
For simple 1:1 synchronous API calls — direct REST is cleaner and faster.
When the team can’t support monitoring (queues need visibility and alerts).

As an analyst, you don’t have to design Kafka topics or RabbitMQ exchanges.
But you should recognize the moment when a queue turns from “technical detail” into a business enabler — ensuring reliability, scalability, and peace of mind for everyone involved.

For Business/System Analysts who work with ERP integrations.

Andrii Siryi — Tue, 28 Oct 2025 15:42:00 GMT

When designing ERP integrations (for AR/AP document flows), Business/System Analysts often face a range of “gotcha” questions — technical, architectural, and sometimes unexpected.
Here are some of the real-world questions I ask clients during the API and ERP connector discovery phase:

What’s the minimum required ERP version to support all AR/AP endpoints?
Could upgrading the ERP version change the API behavior (fields, formats)?
Are there any heavy or slow API methods under load? Recommended workarounds?
Does the ERP provider charge for API calls, or is usage unlimited?
Can we get a list of possible API error codes?
Any record count limits per request? (e.g., max 1000 records in GET)
What type of authentication is used — Basic Auth, OAuth2, or token-based?
What’s the average response time of the API?
Are there any debug/logging tools if something goes wrong with the call?
Any breaking changes in recent patches that could affect us?
Does the API support batch insert/update or only record-by-record?
In what format are dates returned? Full datetime or date-only?
How are balances returned (positive/negative for credit memos)?
Can documents be posted without updating the "last modified" date?
Can an account include multiple subsidiaries? How to filter by them in the API?
Are any API methods planned for deprecation? What will replace them?
Are some API endpoints available only with paid ERP modules or add-ons?
Are some fields or features hidden unless specific ERP configuration settings are enabled?
Does the ERP API return full relational data (e.g., linked documents, GL splits), or do we need extra queries?
How can we detect deleted records if the API doesn’t expose a deleted flag or status?

These questions aren't just technical — they help avoid costly mistakes, failed syncs, or misunderstood logic.

Field Mapping vs. Canonical Data Model — Which One Wins in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:39:00 GMT

When building integrations between systems, one of the first architectural choices you’ll face is how to align data between them.
Two main approaches dominate this conversation: direct field mapping and the canonical data model.
Let’s break them down.

Field Mapping: Simple but Fragile

Field mapping means you connect each field from System A directly to a matching field in System B.
It’s fast to implement and easy to visualize:

Example:
“CustomerName” → “ClientFullName”
“InvoiceDate” → “BillingDate”

Pros:

Quick setup for simple integrations
Easier to debug and understand
Great for 1-to-1 integrations

Cons:

Every new system adds complexity — you end up maintaining dozens of mappings
Any field name or format change breaks the flow
Hard to scale beyond a few connections

This approach is fine for small, stable environments — like syncing data between CRM and ERP once a day.

Canonical Data Model: Structured and Scalable

A canonical model introduces a shared, unified data layer — a kind of “translation dictionary” for your enterprise.
Instead of connecting systems directly, each system maps to the canonical schema.

Example:
System A → Canonical Model → System B
“CustomerName” → “Customer.FullName” → “ClientFullName”

Pros:

Greatly simplifies multi-system integrations
Reduces maintenance costs over time
Makes it easier to add or replace systems

Cons:

Requires more design work upfront
May be overkill for small projects
Needs governance and version control

This approach shines in large ecosystems — where data flows across multiple ERPs, CRMs, or custom apps.

So… Which One to Choose?

If you’re connecting two systems and don’t expect frequent schema changes — use field mapping.
But if your integration landscape is growing and you want to reduce long-term pain — invest in a canonical model early.

Think of field mapping as a shortcut, and the canonical model as a foundation.

YAML-Based Story Mapping

Andrii Siryi — Tue, 28 Oct 2025 15:37:00 GMT

System Analysts who work with integration processes should formulate user stories in a way that diverges from the traditional structure. This is primarily due to the need for a more technical and structured description, which allows for the inclusion of integration-specific details.

The user story might need to specify exactly what kind of data should be retrieved via an API, from which system, using what HTTP method, and so on.
Additionally, such user stories can incorporate validation requirements.
For instance, before sending the data to an external system through an API, certain transformations or formatting might be required.

As a result, the structure of a user story in this context tends to differ significantly.

Here’s an example of how a story might look:

story_map:
epic: "Invoice Integration"

user_stories:

id: US001
title: "Obtain AR invoice"
as_a: "Application X"
i_want: "obtain AR invoices from ERP {{X}} via API"
so_that: "I can handle this invoice and send to the client"
source_system: "ERP {{X}}"
target_system: "Application X"
direction: "pull"
api_call:
method: "GET"
endpoint: "/api/invoices"
auth_required: true
id: US002
title: "Validate data"
as_a: "Application X"
i_want: "validate the fields of the received invoice"
so_that: "I don't sync the invoice with errors"
validation:
invoice_number: "required"
invoice_id: "required"
invoice_total_amount: "should be > 0"
invoice_status: "should be 'posted'"
id: US003
title: "Push invoice payment"
as_a: "Application X"
i_want: "push the invoice payment created in Application X to the ERP"
so_that: "the payment is approved in the ERP and synchronized back"
source_system: "Application X"
target_system: "ERP {{X}}"
direction: "push"
api_call:
method: "POST"
endpoint: "/api/payments"
auth_required: true

Power BI: Your Key to Data-Driven Success

Wheeler55 — Wed, 21 Jun 2023 11:09:00 GMT

Introduction

In today's data-driven world, businesses are constantly looking for ways to gain valuable insights and make informed decisions. Power BI, a powerful business intelligence and data visualization tool developed by Microsoft, has emerged as a game-changer for organizations across various industries. In this article, we will explore how Power BI can unlock the potential of your data and help you achieve success.

Understanding Power BI

Power BI is a comprehensive suite of business analytics tools that allows you to analyze data and share insights. It consists of various components, including Power BI Desktop, Power BI Service, and Power BI Mobile. With Power BI, you can connect to a wide range of data sources, transform and model your data, and create interactive visualizations and reports.

Benefits of Power BI

Using Power BI offers several benefits for businesses:

Data Visualization: Power BI enables you to create interactive visualizations that make it easy to understand complex data.
Data Exploration: With Power BI, you can explore your data in real-time, drill down into specific details, and discover hidden patterns and trends.
Data Collaboration: Power BI allows you to collaborate with team members by sharing dashboards and reports, facilitating better decision-making.
Data Mobility: Power BI Mobile lets you access your data and reports on the go, ensuring you stay informed wherever you are.
Data Security: Power BI offers robust security features, ensuring your data is protected and only accessible to authorized users.

Getting Started with Power BI

To get started with Power BI, follow these steps:

Download and Install Power BI Desktop: Visit the Microsoft Power BI website and download the Power BI Desktop application.
Connect to Data Sources: Connect to the data sources you want to analyze, such as databases, spreadsheets, or cloud services.
Transform and Model Your Data: Use Power Query to transform and clean your data. Apply data modeling techniques to create relationships between tables.
Create Visualizations: Build interactive visualizations using the drag-and-drop interface of Power BI Desktop.
Publish and Share: Publish your reports and dashboards to the Power BI Service to share them with others.

Key Features of Power BI

Power BI offers a wide range of features to enhance your data analysis and reporting:

Interactive Dashboards: Create visually appealing dashboards with interactive tiles that provide a holistic view of your data.
Natural Language Query: Ask questions in plain English and get instant answers from your data using the Q&A feature.
Data Alerts: Set up alerts to receive notifications when specific data conditions are met or exceeded.
Scheduled Data Refresh: Ensure your reports and dashboards are always up to date by scheduling regular data refreshes.
Data Drilling: Drill down into your data to explore details and uncover insights at a granular level.

Power BI Desktop vs. Power BI Service

Power BI Desktop and Power BI Service are two components of Power BI that serve different purposes:

Power BI Desktop: This is a Windows application that allows you to create reports and visualizations on your local machine. It offers advanced data modeling capabilities and is ideal for creating complex reports.
Power BI Service: This is a cloud-based platform where you can publish, share, and collaborate on your reports and dashboards. It provides browser-based access to your data and allows you to view and interact with reports on any device.

Creating Visualizations in Power BI

Power BI provides a wide range of visualization options to bring your data to life:

Charts and Graphs: Create bar charts, line charts, pie charts, and more to represent your data visually.
Maps: Plot geographic data on interactive maps to identify regional trends and patterns.
Tables and Matrices: Display data in tabular format or create cross-tabulations using matrices.
Gauges and KPIs: Use gauges and key performance indicators (KPIs) to track progress towards goals.
Custom Visuals: Extend Power BI's capabilities by adding custom visuals created by the Power BI community.

Data Transformation and Modeling

Power BI offers powerful tools for data transformation and modeling:

Power Query: Use Power Query to extract, transform, and load data from various sources. Cleanse and reshape your data for analysis.
Data Modeling: Build relationships between tables, define calculated columns and measures, and create hierarchies for advanced analytics.

Sharing and Collaboration in Power BI

Power BI enables seamless sharing and collaboration:

Publishing: Publish your reports and dashboards to the Power BI Service to make them accessible to others.
Sharing: Share your reports and dashboards with specific individuals or groups, controlling their level of access and permissions.
Collaboration: Collaborate with team members by co-authoring reports, leaving comments, and engaging in discussions.

Security and Governance in Power BI

Power BI prioritizes data security and governance:

Row-Level Security: Implement row-level security to restrict access to specific rows of data based on user roles.
Data Encryption: Protect your data with encryption both at rest and in transit.
Data Gateway: Use the Power BI Data Gateway to securely connect to on-premises data sources.

Integrations with Other Tools and Services

Power BI seamlessly integrates with various tools and services:

Azure Services: Leverage Azure services such as Azure SQL Database, Azure Data Lake Storage, and Azure Machine Learning to enhance your data analytics capabilities.
Microsoft Office Suite: Integrate Power BI with other Microsoft Office applications like Excel and SharePoint to create a unified data ecosystem.
Third-Party Services: Connect Power BI to third-party services like Salesforce, Google Analytics, and Adobe Analytics to consolidate your data sources.

Power BI for Business Intelligence

Power BI empowers businesses with actionable business intelligence:

Real-Time Monitoring: Monitor key performance indicators in real-time to make data-driven decisions promptly.
Data Discovery: Discover hidden insights and trends in your data, enabling proactive decision-making.
Self-Service Analytics: Empower business users to create their own reports and dashboards without relying on IT teams.
Executive Dashboards: Provide executives with a consolidated view of business performance, enabling strategic decision-making.

Power BI for Data Analysis

Power BI enhances data analysis capabilities:

Ad Hoc Analysis: Perform ad hoc analysis by exploring and manipulating data on the fly.
Advanced Analytics: Leverage advanced analytics features like forecasting, clustering, and sentiment analysis to gain deeper insights.
Machine Learning Integration: Integrate Power BI with machine learning models to perform predictive analytics and automate decision-making processes.

Power BI for Decision-Making

Power BI enables data-driven decision-making:

Data Visualization: Visualize data in a way that is easy to understand, facilitating quick decision-making.
Collaborative Decision-Making: Share reports and dashboards with decision-makers to foster collaboration and alignment.
What-If Analysis: Conduct what-if analysis by changing variables and observing the impact on outcomes.
Predictive Analytics: Leverage predictive models to anticipate future trends and make proactive decisions.

Conclusion

In conclusion, Power BI is a powerful tool that empowers organizations to harness the power of data for better decision-making. By leveraging Power BI, businesses can gain valuable insights, uncover hidden trends, and make informed decisions. With its intuitive interface, extensive features, and seamless integration capabilities, Power BI provides users with the opportunity to learn Power BI and unlock their data-driven potential. Whether you are a small business or a large enterprise, Power BI offers a scalable and cost-effective solution for data analysis and visualization. By embracing Power BI, businesses can embark on a journey of continuous learning and growth, propelling them towards data-driven success.

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

A Comprehensive Guide to the Major Business Analyst Deliverables?

Digvijaybook — Sun, 12 Apr 2020 05:21:00 GMT

The role of a business analyst is to manufacture a piece of art; the piece of art varies depending upon the methodology and techniques being used. Business analyst serves the project all through the beginning until the end and comes up with different pieces of art. It all depends on the case, the business analyst gets involved from the beginning of the project in the pre-sales, feasibility stage and goes further till the project ends into the operations and maintenance stage.

The artifacts created by business analysts go through different stages, and not all need to be presented to clients and stakeholders of the project. It is very essential to undertake all the principles and also considering the time while creating such items, and how they vary based on the project approach.

Business Analysis Body of Knowledge (BABOK) states about the two different forms of artifacts:

1. Work Product - A work product is a document where all the collection of notes and diagrams are used with the help of a business analyst all through the development process.

2. Deliverable - A deliverable is an exceptional and certifiable work product or service, where the party gives consent to delivery.

Difference between Work Product and Deliverable:

A business analyst must understand the difference between a work product and a deliverable. A work product states as a work in growth, unstructured and unsolved if shared with a stakeholder. A work product is used for gathering or shows the information and should not be taken as an absolute product for delivery until and unless proper structuring is done, with full information and evaluated.

For a business analyst, it’s not only the single work to do. His role has got so much to do as a business analyst encompasses few value-adding activities. Following are the categories that make sense as concerned with deliverables:

1. Understanding the Business

This is the first step for the job where you have to figure out where the business needs attention and to be solved. This is not particularly done by business analysts because you have to outline the returns on investment, giving a business a good reason and so on; for which business analyst needs to be prepared. It always varies from company to company, business analyst differs or refers to too many other identities and titles. My company, such as, calls it an IT Partner, normally partnering with a specific business segment such as marketing, sales, etc.

A business case as a High-Level Deliverable:

A business case is generally taken as an outcome of this, and it might take into account the output of different techniques that come together to illustrate that a problem needs a solution or there is an opening that takes an added advantage.

2. Planning Your Work

Once the decision has been made for a particular project; then it’s time to plan and decide as to how you will be doing the project as a business analyst. Planning is very essential and that too at initial stages because a business analyst can’t do the job all of his own. An analyst has to work out and outline the needs as to how they are going to work together with the stakeholders and acquire all the needs that need attention and the best possible solution that would work for them. Everybody’s involvement is required and they also make sure that all the resources such as people, tools, facilities, etc are provided as per the need. This step is meant to be very important as the contractor and statements of work will be required well on time.

Business Analysis Approach towards a plan should be High-Level Deliverable:
By the term high-level means that whatever comes out of this may be included in the planning of business analyst; as they might be broken down in small common deliverables such as work breakdown structure (WBS), communication plan, planning towards business analyst approach (Discussed below in detail) and necessity plans to manage.

Business Analyst Approach:

Following are the elements of the Business Analyst Approach:

- Background - States the purpose of the project and also provide background information.

- Business Drivers - This is the reason why the initiative is made with a purpose. Building up business needs at high levels that establish the reason for the project.

- Problem Statement - This statement states the reason for the project concerning the business term such as the importance required for new projects.

- Vision - Vision states the inspirational explanation as to what the company aims to achieve and accomplish.

- Scope - Focus on the boundaries that need changes.

- Dependency - Dependencies create a link, type of links, among all the tasks of the project and with other projects at the same time.

- Roles and Responsibilities - States the roles and responsibilities of the people performing the project.

3. Defining the Solution

This is the main role that people expect out of business analysis and especially what all deliverables are more or less required. Stating the solution is fundamentally required, as all solutions are required to meet the business needs and requirements, also called as requirement gathering.

Must have Documents- High-Level Deliverables:

This can vary with sizes and shapes; the main need in term of document it means that it should be a paper document but that’s not mandatory. By BABOK it is term as to be the “requirements package” that illustrates in a better way. This might comprise of traceability matrix, use cases, necessary solutions, meeting stakeholder needs, business compulsions and these can be in unusual forms such as diagrams, models or wireframes.

4. Evaluating the Solution

The solutions that are provided should be checked to evaluate and to meet business needs and requirements. This can be done in two ways:
a. When the required documents are done, solutions are intended and you are sure that your business needs are fulfilled.
b. When the required documents are done and you have to evaluate different possible solutions e.g. you want to buy a car and you make a list of cars you are interested in and you will see which car model works well for you instead of making your car.

Evaluation and User’s Acceptance test for High-level Deliverables:

Acceptance and evaluation both play a very important role when putting together because it is very important to accept. It makes sure as to whether the purchase made or been built is meeting all the needs and requirements. The process of evaluation is usually deciding which option works for you. This can be done in the form of user acceptance test criteria, vendor selection criteria and more.

Conclusion

With the change in the demand of the customers and their respective needs and requirements for the best products and customer service has made all the manufacturers for better business operations. So, it is very important for companies to accept the changes required and opportunities that have the potential to become successful Business Analyst. In short, it can be said that business analysis is nothing but identifying the needs of the customers and providing the best possible solution. Also, keeping in mind how well structured your Business Analysis Approach planning has to be and to understand all the considerations taken into concern before embarking on executing any form of Business Analysis Approach.

Possible types of Requirements to Discover

Heta Raval — Fri, 16 Aug 2019 08:21:00 GMT

In a current scenario, when you are eliciting software service-based requirements then, you may be able to derive requirements in certain varieties. In the beginning, they can be just functional or non-functional requirements. But when you come across many other requirements as time goes, you can conclude requirements into several categories and will be able to take decisions...

As mentioned, requirements can be functional or non-functional. It is simple to determine both the type of requirements for an example, in a context to an e-commerce application, a user clicks on "Shopping Cart" button, they will be able to view the list of the total purchase to be done. So this can be a functional requirement, where there is a user need to 'View' their shopping cart.

Likewise, functional requirements, non-functional requirements can also be critical. They assure usability, performance, effectiveness, and security. If they fail to accomplish, then it can turn out failing the satisfaction of the business needs. For example, the payment procedure for any e-commerce site shall be secured and efficient enough to make the payment by the customer. These non-functional requirements are performance-based requirements which the stakeholder needs to establish.

There are mainly three types of requirements to elicit, which I have identified throughout my experience. As requirements can have a different type of business cases, domains, and demands, it is also essential to measure their outcomes. Therefore we need to identify which type of requirement is it.

Business Requirements
1. This type of requirements is based on assumptions as they are high-level specifications and collected from other business cases. Here the stakeholder has just an idea of his business obligations, but they are not knowledgeable of individual use cases.
2. You need to take visualization in defining functional requirements. Imagine the workflow for the system and navigate the user functionalities with the flow. Once it has done, apply it by creating wire-frames. These wire-frames would help a lot to attract stakeholders as you are providing them the visuals.
3. You can provide the blueprint or we can say the skeleton of the future website to ensure the stakeholder that you are visualizing the exact vision of the requirement.
4. Visuals are more persuasive than a document which contains only written content. Visuals are more precise and easily understandable. It will give ease to keep the ball into your court because these requirements are based on assumptions which can be helpful to generate better revenue for your organization.
Structural and Design Requirements
1. A requirement which falls into this category is simple, and straightforward to extract because the structure, design, and layout of the project have already decided. So they are accurate, and the user navigation could have seen as mild. Also, they are more detailed than business requirements.
2. The stakeholders are already fond of any other business cases, and they want the same type of outcome to get achieved. Therefore, it is easy to analyze this kind of requirement.
3. You don’t need to worry about all the use cases for the requirement nor about layout and design. All you need is to analyze all the functionalities used within the given business case.
System Integrated Requirements
1. These are a very low level of the requirements where you will have system and integration to make into the system. It is a detailed narration of every use cases of the system.
2. The stakeholders know the specific part of the development to get it done by you. You merely need to review their existing work and map it with the current requirement.
3. They are having sufficient details so that developers can begin coding. But you need to be careful and aware of every functionality to make the requirements more effective.

Here, the conclusion to my thought will be that plan out requirement elicitation process and document all the functional, non-functional requirements so well with validation so that your team will be more efficient to work on it.

How to write an effective Approach for Requirement Analysis

Heta Raval — Fri, 16 Aug 2019 07:51:00 GMT

It is essential to write an impressive approach which helps you to make a client convinced about your understanding of his requirement. The satisfactory approach would help you to be on the same page with the client. So, your chances to get the contract/project would raise. In order to provide a technical solution, a business analyst needs to recognize the demand and purpose of the business.

The approach writing focuses only on the process to achieve the business requirement. Here are some significant steps to write an authoritative approach.

Identify the Core requirement
- Once the analysis part, the first step while writing an approach shall be the identification of the heart of the requirement. Write the basic understanding with the core identification of the scope of business.
- At the first stage of an approach, the client should feel satisfied enough from our understanding of the core part of the requirement. The client should feel that we would provide an essential solution.
- Explain the basic functionalities of the proposed business in such an impressive and in a brief way. Nowadays people don't like to read long phrases, explanations, understanding for the same points. Therefore the scanty strategy is adapted to impress the client.
Appoint Business Cases
1. Identify the possible business cases which are obligatory to consider to achieve the solution. List down all the business cases and divide the requirement into individual modules.
2. These modules shall be providing the explanation/understanding of the relevant functionalities.
3. These business cases shall be written in such a way, that it covers the need of business cases with their risks and benefits. The business cases are going to be the base of the requirement. Therefore they shall be written clear and concise sufficiently as they will be used to communicate the intended audience.
4. Include different types of business case diagrams wherever require, which would provide the acceptance as “Short and Sweet” judgments that would be helpful to highlight the work done from your side.
Solution Evaluation and Implementation
1. Once all the business cases are defined, one should write up the way of how those cases will be implemented. Write solution for each business case that how it is going to be implemented, which technology will be used and why. Also, write about the reasoning for the selected strategy as a solution chosen.
2. The workflow shall be written as a guideline in a seamless and obvious way to a non-technical reader as well.
3. The workflow shall be clear and precise that would help to win the client’s mind with an impressive way. As being a service provider, you should be able to convince the client that you have thorough knowledge about the problem which the client has and you will provide the perfect solution.
Core Assumptions
1. It is essential as well to keep a ball in your court. Therefore, each and every assumption shall write in the approach. With these assumptions, you are clearing all the crucial points which match the client’s requirements but, which are not clearly mentioned by the client.
2. Why the assumptions are necessary is because they are offering a faith of you to be true in the future.
3. Make assumptions based on the knowledge you have, your past experiences, and the information is available from the client.
4. They are anticipated conclusions or circumstances which are expected to occur during the project's life cycle.
Relevant & Required Queries
1. One should ask all the doubts and queries for the unclear functionalities and workflow.
2. Being a service provider, you should ask queries which are related to the functionalities and for the project. The queries should be specific, relevant, and easily recognizable.
3. Always include polite and kind words in the queries, when you are requesting if something is totally not clear or you need the client’s inputs.
4. The queries shall be written in such a way that after, you are totally clear with all the functionalities related to project. More relevant queries would show good analysis practice.

Concluding Considerations

The project proposal approach shall be the one such document which covers all the elaboration for requirement analysis with evaluation, assumptions, and queries. It must be convincing and impressive enough as per the document’s name suggested, you are going to approach someone with whom you want to collaborate your work. With the conclusion, an approach should be precise, simple, and qualified to achieve the desired project.

Requirements In Context Part 2: The Functional View From 10,000 Feet

Dan Tasker — Mon, 29 Apr 2019 00:49:00 GMT

In Part 1 of this series it was stated that the overall objective of these articles is to improve the quality of requirements produced by business analysts. Following the adage that “Context is Everything” it established that a number of different contexts will be explored. And in keeping with this principle it set business information systems as the context of the requirements to be addressed.

Classic Business Functions

My very first position as a business analyst 30 years ago was with a company that had just completed an enterprise-wide planning effort.⁽¹⁾ They had gone so far as to remodel one of their conference rooms for the specific purpose of displaying the results on multi-layered whiteboards. The most prominent board displayed a functional model of the business. It was said to be a view of the company from 10,000 feet up. The functions were organised into three categories: Management, Support and Line of Business.The following diagram is a slightly simplified version of that model:

In my first article I presented the classic “Swings” cartoon. It is a classic because it has remained relevant all these years. I consider the high-level functional model presented above to be a classic. It too has stood the test of time. Throughout my years as a business analyst, working in a wide variety of industry segments and government agencies in three countries, this model has proved to be both relevant and useful.

Not all organisations utilise every one of the functions shown. And some organisations have multiple lines of business. For example Walt Disney - Film production would be one, theme parks another. In this style of model, each would have its own ‘Line of Business’ functions to provide contexts for dealing with very different products. Regardless of the numbers of lines of business, the Management and Support functions are applicable across the organisation.

Enterprise Resource Planning

Thirty years ago using a model like this to plan an organisation’s business information systems was leading edge. Database management systems had been around just a few years. Their use typically involved one-for-one replacement of application-specific files. A batch processing inventory management system would be upgraded to an online inventory management system supported by an inventory database. A batch processing sales management system would be upgraded to an online sales management system supported by a sales database. And on and on.

High-level functional models like this were used to demonstrate to the organization that a shared set of data could and should be used to support multiple functions across the business. The idea was to stop developing application-specific information systems and start developing an enterprise-wide one. Fast forward to today and this vision has become business as usual for many organisations.

It is common today for an organisation to have a relational database that holds data utilised by multiple business functions. Some of these systems have been developed in-house. Others utilise one of the commercially available Enterprise Resource Planning (ERP) systems. Probably the original and best known of these is SAP. The following is a list of integrated SAP modules that an organisation to pick and choose from:

Human Resource Management
Production Planning
Material Management
Financial Supply Chain Management
Sales and Distribution
Project System
Financial Accounting and Controlling
Plant Maintenance
Quality Management

Quite a striking correlation between these modules and the high-level functions from that 30 year old model.

High-level Requirements From High-level Functions?

This series of articles is about requirements in context. The Functional context is where we are starting. The functions from the 10,000 foot level are the most general functional context I can imagine. Could these be used to draft requirements? I can think of one scenario where they could - an organization interested in acquiring an ERP system. Here is an example of one such high-level requirement:

The system shall support Accounting processes integrated between themselves and with processes of other functions.

Each ERP function the organisation is interested in should have its own requirement naming a high-level function it wants within its integrated system. Each would be assigned its own priority. Some would likely be must haves while others might only be nice to haves. (Who am I kidding? – we all know that to business users every requirement is a ‘must have.’)

Processes within Functions

The view from 10,000 feet is an interesting functional context, but outside of acquiring an ERP system we need business functions closer to earth. Fortunately the majority of functional modelling techniques include the concept of functional decomposition. That technique used to produce the model above offered a simple three-level decomposition scheme. The things at the top level were called Functions. A level below functions were things called Processes. The third and lowest level things were called Activities.

Functions were considered to be ‘ongoing’ activities. A person working in Accounting or HR does their job year round, year in and year out. Processes in the context of this model were defined to be things that have a start and an end point. A given Function typically would decompose into 10-ish Processes. Again using SAP as an example, we see its HR module breaks down into 12 processes:

Organizational Management
Personnel Administration
Recruitment
Payroll
Travel Management
Personnel Management
Time Management
Compensation Management
Training and Event management
Wages
Personnel Development
Workforce Administration

It’s easy to envision most, if not all of the above processes having start and end points. For example, while it could be argued that Recruitment goes on continuously, in reality filling a specific position starts with some form of notification of the opening and ends ideally with a successful candidate coming on board. Here is an example of a high-level requirement utilising a Process context:

The system shall support the recruitment process including keeping records of published notifications, candidates, interviews and proof of fairness during the selection process.

Activities within Processes

The term Activity can be defined as the individual steps in a process. Visualise a workflow diagram. The boxes in the diagram that don’t themselves require further decomposition would be considered activities. The basic idea is that an Activity is that it should be simple enough that an individual is able to complete it in a single ‘sitting.’ No need to hand the work off to anyone else mid-activity or to have to wait for some other activity to complete. An example of an activity within the Recruitment process would be one called “Make Offer to Candidate.” An example of a high-level requirement ustilising an Activity as a context would be:

The system shall support keeping a record of offers made to selected candidates.

I have used a variety of functional modelling techniques from dataflow diagrams to business process modelling notation (BPMN). Regardless of the terminology used in any particular method, I have found the definitions of the three functional levels presented above to be excellent guideposts for both functional modelling and drafting requirements.

Next Time – Project Scope as a Context for High-Level Requirements

Gathering of requirements is typically managed within a project, and part of managing a project is establishing its scope. Requirements are expected to address the things within this scope. Next time we will look at scope and how high-level requirements can be derived directly from it, and actually as part of the scoping effort.

(1) The enterprise-wide planning methodology utilized by the company described was called Strategic System Planning (SSP) developed by Robert Holland.

Requirements in Context Part 1 - Just Know It!

Dan Tasker — Mon, 22 Oct 2018 20:23:00 GMT

I have long been a believer in the saying “Context is everything.” As a business analyst dealing with business users, understanding the context of the topic of discussion is essential. In thinking about what constitutes quality requirements it occurred to me that there are a number of additional contexts that play a role. Examples include the organizational maturity level (from Informal through to Optimized) and delivery context (green fields through to package acquisition).

This is the first in a series of articles about business requirements. My primary objective is to help business analysts improve their elicitation and documentation of requirements. With an increased awareness of multiple contexts I believe that the quality of the requirements documented can be improved, and subsequently lead to the better design, development and implementation of business systems.

Mark Twain is credited with saying, “Everyone talks about the weather, but nobody does anything about it.” The equivalent saying in the IT context would be, “Everyone agrees that good requirements are essential, but nobody does anything about them.”A perfect illustration of this is the classic IT cartoon “The Swings”:

What is not funny about this cartoon is that the situation it depicts is as true about business systems delivered today as it was when the above version was published. Over 40 years of struggling, and most often failing to meet user expectations, in spite of unimaginable improvements in technology.

I have no illusions that what I intend to present will magically make it all better. But these articles are at least my attempt to do something about it. If you are reading this it means you are interested in improving your BA skills. Hopefully learning about the impact of different contexts on requirements will lead to that.

The Business Information System Context

I find it virtually impossible to take off my business analyst hat. Any time a family member or friend mentions that they want something – a new car, an electrical appliance, I immediately go into ‘requirements mode.’ I start asking questions intended to help them focus on their thinking in order to lead to making the best choice. It occurred to me that it as I begin to present the various contexts related to requirements that I should set the context for this series of articles. The context of requirements that I intend to focus on is business information systems. And while a complete information system includes a hardware and a network aspect, the requirement contexts that will be discussed will not include these technical aspects. The requirements contexts will focus on business analysts interacting with business users to deliver the functional and information components of a system.

Please note that when I use the term ‘system’, from a requirements perspective that doesn’t mean that every requirement will result in a computer-based solution. Having gathered requirements a subsequent exercise is to determine which of them will be given automated support and which will be left as manual processes.

Functional and Information Components

The earliest “computers” were primarily electronic calculators. They allowed complex formulas to be broken down into individual computational steps. Having expressed these steps in a language the computer could understand the resulting instruction set was ready to receive the data to be manipulated. The end product was a set of calculated results.

When businesses began using computers their objective was to maintain data about their business. Computational requirements were minimal. Simple things like adding or subtracting deposits and withdrawal amounts from a customer’s account balance. The original computerized business systems all performed their functions by reading in batches of data, operating on each record as it went through the system, and producing individual results before the next record was processed.

With the advent of database management systems and access in ‘real time’ to computer applications, more and more business processes could be supported by computers. Today virtually every office worker has a computer on their desk. And thanks to wireless networks and portable devices workers (and customers) outside of the office have access to the information they need when they need it.

With the focus of business information systems being the support of functions that capture and utilise data I offer a variation on the Nike slogan “Just Do It”. The objective of the business information systems we gather and document requirements for should be “Just Know It.”

Functional Context / High-level Requirements

Having established the context for these articles to be business information systems, the journey itself will begin in the next article. In it I will present a technique I have used for many years to help establish the functional context for a requirements gathering effort. The more common term for this functional context is “Project Scope.”

I will also discuss the possibility of combining the scoping exercise with the producing of high-level requirements. The result of doing this reduces that requirements task down to hours rather than days (or weeks). This will be the first of several demonstrations of the strength of applying the thinking that “Context is everything.”

Next article: Requirements In Context Part 2 - The Functional View From 10,000 Feet

Identifying requirements, the right way

Surbhi Mahnot — Mon, 10 Apr 2017 06:10:00 GMT

Requirements define the needs of the project to provide best of its utility and benefits. If they aren’t clear or analysis is not done properly, it might lead to failure of the project no matter how good the concept and design is.

Just as a system is composed of various functionalities, requirements too are identified in various forms. This categorization of requirements makes analysis process much simpler and clear for all the involved stakeholders. As per BABOK, the requirements are primarily categorized as:

Business Requirements
Stakeholder Requirements
Solution Requirements - Functional and Non-Functional Requirements
Transition Requirements

With so many requirements to identify it is very easy to get confused with how to identify these requirements?

A simple approach is to visualize the complete process and start step by step

To do that, let’s look at cooking for an example:

When you plan to cook a meal, you first take in account for whom you are cooking. Is it for yourself or for your family or the kids? These define your Business Requirements. Once you decide this, you figured that you will sip wine along with the food and the kids won’t eat spicy food (stakeholder’s requirements). Next, you get all your ingredients for the meal (functional requirements) and you might also take in consideration the time you require to prepare the meal and preparation required for serving the food (Non-functional requirements). Finally, you prepare a delicious penne arrabbiata pasta topped with oregano and basil leaves (technical requirements).

Now, let’s understand each of these requirements with a technical example, Implement Log-in functionality.

Business Requirements: These are high-level business objectives or goals or needs of an organization. The business requirements document (BRD) usually includes what features would be there in the product, what market the business will expand or enter, risk assessment, success measures from the business point of view, etc.

Example: There shall be a Login screen through which Users will log into the system.

Tip to identify:

Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Stakeholder (User) Requirements: These are what every stakeholder needs/expects from the solution and how they will interact with the solution. Often the stakeholders can explain the entire system in detail from their perspective only. Each stakeholder sees the problem from unique perspective. Therefore, you must understand all the needs to understand the complete system. All these requirements must be analyzed in such a manner that it doesn’t conflict with each other.

Example:

As a customer, the user shall be redirected to Dashboard on successful login. (Stakeholder - Customer).

As an admin, the user shall be redirected to the Administrator’s landing page on successful login. (Stakeholder - Administrator).

Tip to identify:

Similar to business requirements, but from user's perspective. Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Solution Requirements: These specify the detailed conditions and the capabilities that the solution must have to meet the business and stakeholder requirements. Software Requirements Specification (SRS) is created to capture both functional and non-functional requirements. These are categorized into two:

a. Functional Requirements: These define specific behaviors, responses, information, rules for the solution primarily addressing the following:

The features the system will support (Functional capabilities)
Data validation rules and how they will be managed (Business Rules)
Interaction between different stakeholders (users) within the system (Use cases)

These include a complete description of ‘how’ the system will be built.

Example:

Registered users shall be able to login with valid username and password
On successful login, user shall be redirected to a landing page in the system
On failure, for not registered username prompt "Username not registered" message and for invalid credentials prompt "Invalid credentials"
New users shall be able to register with the system by clicking on the "Sign-Up" link
Users shall be able to recover password by clicking on "Forgot Password" link

b. Non-functional Requirements (Quality-of-service): These define the environment in which the solution will operate. The qualities a solution must have or constraints within which it must operate smoothly. They define standards for Usability, Reliability, Security, Accessibility, Performance, Information Architecture, Portability, Extensibility, Internationalization, Integrity or anything that would help the success of the system in real-world.

Example:

Performance: On successful login, user shall be redirected to the landing page within 10 seconds (max)
Maintainability: Proper logs stating the operation result with timestamp shall be added on every login/signup/forgot password click
Platform: The login functionality shall behave same on different platforms (Windows/Linux)

Tip to identify:

To easily identify between these, functional requirements can be considered as “verbs” and non-functional requirements as “adjectives” on these “verbs”.

Transition (Implementation) Requirements: These define conditions or capabilities only required to enable transition of the solution from development to real-word business use. It describes what must be done with the process, technology, education, training, enhancements before getting from the as-is into the to-be.

Example: Not valid in this example but for explanatory purpose: The login system shall behave same once "Single Sign-On" functionality is implemented

Tip to identify:

Look for temporary requirements such as “migrate from old system to new system”.

There are many other types of requirements that are used across diverse types of systems based on the scope such as:

Technical Requirements: Once the solution requirements are clear, the best way to start with the development frequently involves technology. It is a way to communicate between analyst and engineers (programmers, architects, designers) and is often written by the technical engineers. These requirements specify design and architecture for the solution components to be developed and implemented. They define how the solution will be programmed, store data and display data.

Example:

Browser support: Current and recent versions of Firefox, Edge, Chrome, Internet Explorer, Safari, Opera
Requires browser to have JavaScript enabled

Tip to identify:

Technical jargon's are used such as “password encryption algorithm” and “database schema” etc.

User Interface Requirements: These define the user interface design for the functionalities (derived from solution requirements). The placement of user input controls, buttons, links etc. on screen to allow the working of the functionality. Generally represented with wireframes.

Example:

Textboxes for username and password shall be placed below the respective labels for Username and Password
Login and Cancel buttons shall be present in center of the screen
Sign-Up link shall be present below the Login button
Forgot password link shall be present above the Login button

Requirement analysis is all about understanding, identifying and categorizing these requirements. With categorized requirements, it becomes much simpler for the team to understand and follow the system details.

#requirements

Defining Requirements

Surbhi Mahnot — Thu, 16 Mar 2017 12:47:00 GMT

All professionals talk about identifying business needs, identifying requirements to create tools so that they can help businesses take better decisions. In your career as an IT professional, I am sure at some point you must have heard terms such as “Requirements”, “Business Requirements”, “Software Requirements”, “Project Requirements”, “Technical Requirements” and the list goes on.

So, what are these requirements?

“Ours is a world where people don’t know what they want and are willing to go through hell to get it.” — Don Marquis

Well, to most of the people, this appears to be a simple question. But, this is the most complex question to answer (for the professional responsible to gather requirements, primarily a Business Analyst) as it takes forever to ask and understand “What are the requirements”.

Different people have different ideas of requirements. For a product owner, requirement is as simple as the ability to use/sell the product that helps with the business and revenues. For a project manager working on that solution, requirements are to get the solution developed with best quality that meets all the expectations of the client and minimize resource allocation to bring most benefits to the company. For a team lead, requirements are to identify the technical challenges, build a maintainable architecture and get the solution developed smoothly. For a developer, requirements are to develop the assigned feature or make changes in the software as requested.

Requirements, at first glance are really needs (end objective), wants, suggestions or ideas. Derived from those needs, we set an objective and take a decision about what things should be done or not to be done to achieve that objective.

Requirements are a set of prioritized needs from all the involved stakeholders that form the base for the functionalities or features to be included as a part of the solution.

Per BABOK guide, official definition of requirement is:

1. “A condition or capability needed by a stakeholder to solve a problem or achieve an objective.” In simpler words, a decision-making process to derive requirements from needs.

2. “A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.”It is a step where business requirements are drafted as solutions requirements to get started with developing the solution.

3. “A documented representation of a condition or capability as in 1 or 2.” The documentation is itself a requirement as it helps all the stakeholders and consumers in understanding the requirements for the solution.

Where do these requirements come from?

All the requirements arise from a need. We need to understand those Business Needs or the Business Problem Statement. Unless there is a problem, we can’t think of providing a solution. A lot of analysis and research is carried on before requirement analysis to understand the problem. These involve feasibility study, knowing business terms and concepts, cost/benefit analysis, business strategy etc.

A Business Analyst (BA) starts with a broad and general description of what needs to be done and then starts working with key stakeholders to define the project scope (inclusions and exclusions), high-level business requirements, solution requirements, technical requirements and transition requirements primarily.

Talking about stakeholders, it’s important to know about who they are and how critical is their involvement in the project.

Who are stakeholders?

A stakeholder is a generic term for a person or group of people who are involved with the project (directly or indirectly) and have a say in decision making process of the project. They can be:

Executive Sponsor — Mostly concerned about funding of the project and high-level information
Product Manager — Make important decisions for the project and review & approve requirements
Project Manager — Prepares project plan, resource allocation plan, manages the execution of the project and works very closely with the BA (Business Analyst
Subject Matter Experts — Assists in defining project scope, works with the BA to define business rules, processes and user interface

There is a whole set of other roles such as Technical Personnel, Technical Writers, Quality Assurance Personnel, Database Administrators and others who can be important stakeholders in a project, depending upon the needs.

How stakeholders help with requirements?

Since each stakeholder plays a different role in the project, they have different requirements too. Sometimes, what emerges as the biggest challenge for a BA is to extract useful information from all these stakeholders that matches the preferences best with the client’s business. This is because each of them view the project from their own perspective!

To create best requirements for a project, identifying responsible stakeholders is important. There are many techniques available such as RACI matrix. Not all stakeholders are important for every project. It is primary task to identify the right stakeholders and their say in the decisions to keep things smooth in long run. (When all speak, it becomes real hard to reach to any conclusion).

How are requirements identified?

“The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want.” — Steve McConnell

The process to identify requirements from the needs or conditions is termed as Requirements Analysis. A detailed analysis is critical to solution’s success or failure. It involves the tasks as analyzing, documenting, defining, validating, documenting and managing the changing requirements. There are different standards set in different organizations for the requirement analysis though the primary steps could be identified as:

Identify stakeholders
Requirements Elicitation — capture stakeholder requirements through various techniques such as interviews, questionnaire, joint group discussions, prototypes or use cases
Identify requirement categories — categorize all the gathered requirements into functional, non-functional, business, technical or transitional requirements
Analyze requirements — analyze the requirements whether they are clear, complete, unambiguous, consistent and testable
Requirements documentation — requirements are documented in various forms such as Business Requirements Document (BRD) to describe business requirements, Software Requirements Specification (SRS) to describe functional and non-functional requirements, Use cases and User stories (in agile context)

These recorded requirements documents are then collaborated upon to receive feedback from all involved stakeholders. Once the requirements match the needs for the project, it is important to take sign-off to freeze the scope of work and avoid frequent scope creeps at later stages.

Why are requirements important?

Per new research,

Success in 68% of technology projects is “improbable.” Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start
Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their project
Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization

Requirements serve as the basis for the project plan and if there are inadequate or incorrect requirements, entire project will suffer at the end.

They are used as inputs into the design stages of product development
They are important input for verification process for the product developed
They represent what functionalities are necessary for the product

Excellent requirements leave no room for interpretation, confusion or omission of critical details and is easily understandable by everyone involved in the project.

Next time when you start with your project, make sure you have all your #requirements…clear and loud!

Stay tuned for more with requirement types, characteristics and more coming up!

This article was originally published by me on LinkedIn

Are You Being a Design Illusionist?

Paul Crosby — Wed, 07 Sep 2016 14:31:00 GMT

As business analysts, we are often in the fray of designing. Whether it’s a user interface, report or data fed from one system to another; business analysts create interfaces with human beings and systems. Our design choices impact users and other systems in a very real way. This power can go unnoticed even in our own minds.

Have business analysts become illusionists and pickpockets? Both these skill sets require some of the same sleights of hand. The illusionist uses the blind spots and limits of human vision to fool us. If you haven’t had an opportunity to watch the show called “Brain Games” – give it a whirl. It does an excellent job of explaining how an illusionist can fool our sight and point of view. For the pickpocket, it’s the distraction of a conversation, a tap, or a bump to set your mind off in the opposite direction of where you should be focusing while a sleight of hand takes your wallet.

Are we as business analysts playing a role of illusionist and pickpocket when designing our interfaces? Let’s look at interfaces (such as screens and reports) in a broader sense. An interface in my mind is the presentation or “stage” an illusionist would use.

We all believe we have choices and freedom. Everyone in the western world most firmly believes they have great freedom of choice in being able to do whatever is desirable, affordable and of course legal. You can go just anywhere and do just about anything. But when confronted with a system, website or application with a menu of choices, we fail to see how we are hijacked.

We rarely ask the questions:

(1) What is NOT in the interface? Or why are these my only choices?

(2) What is the purpose or goal of this interface? What is it used for?

(3) Why are these options higher or lower on the interface? More visible or less visible as other choices?

(4) Are these choice empowering me or just distracting me from doing what I need to accomplish?

If you have every used a search engine like Google or an application like Yelp, you get a sense choices are made for you and only certain things are being presented for your attention. I have been told the nearest restaurant or gas station is several miles away – all the while standing right in front of one! I usually chalk it up to “well they must not have gotten into the database yet” but now I’m leaning more to thinking I’m being fooled by the choices I’m presented.

Back in the ancient days at the dawn of computerized civilization – something like 40 years ago for you youngsters – computers were called mainframes. Mammoth monsters that would manage large amounts of data, electricity and generate a lot of heat. They required a forklift to move and had to be water cooled.

In those ancient days of computer myths and data Gods, there was but the humble green screen. To get to all the crap stored in that giant mainframe required you to issue the magic commands. By locating the secret words in the sacred text called “Command Line Reference,” you could instruct the mainframe beast to perform feats of great wonder. In other words, there was a giant three-ring binder with all these commands listed in alphabetical order that you were required to memorize and type correctly. The mainframe didn’t tolerate spelling mistakes, and there was no such thing as auto correct. No Google-like “Is this what you mean?” ever appeared on the screen. Even the help key which was supposed to provide assistance rarely did. This was the world of complete freedom from “the menu”. All the commands were in the book and available and granted they didn’t cover everything you wanted to do, but they did cover a lot of stuff you needed to perform. Yes, you had to memorize a boat load of command line syntax because the mysterious book appeared and disappeared as it desired, but you never felt limited rather you just felt a need to search for the right command.

Enter the age of the personal computer. For simplicity, the command line went away. The mouse was born. There was nothing more entertaining than watching grown men in a room holding the mouse with both hands tightly but gently trying desperately to get that arrow moving in the right direction on the screen. “This mouse thing will never catch on” they grumbled. Suddenly the command line was gone, and menus or buttons presented to us. These were your options. Your only available commands. It didn’t take long before I missed my giant 3-ring binder of commands that gave me all the power.

Over time we became to believe that only the commands we could see were the ones of importance. We would become less and less frustrated at not seeing the things we needed. We are restrained by choices of actions presented. Our perception came to be that if it wasn't presented, it wasn't available.

So let’s take this into the modern smartphone age. The other night friends and I were out at a restaurant having a great conversation. The restaurant was closing because it wasn’t that busy and the owner wanted to call it a night. We asked each other the question “let’s continue this conversation – where should we go?”. We all pulled out our smartphones pulling up Google, Yelp, and the other thousand apps on our smartphones looking for a place that was open late. This searching went on for 15-minutes or so. Now I can be a bit impatient with technology and frankly don’t always find it of much help in situations like these. I quit my search letting the others wade their way through the digital data flowing around with smartphones. Then I looked up.

A beautiful park lay right before our eyes across the street, and we didn’t even see it. We believed our only options to find some place were those our smartphones provided. Did those applications tell us about the park? Not one. How about that food truck with the fabulous desserts? Nope. Not a single one. Our illusion of having choices was broken. Sure we got a lot of options, but it was all about the pictures of the menu or comments from other people that distracted us from answering the exact question “Where should we go to keep talking?”. The menu or interface design didn’t answer our actual question at all. It created the illusion of choice by presenting a small subset of options. All said and done the park was bug-free which is a miracle in Minnesota some evenings. Dessert and conversation continued for hours in the street lamp lit park.

As business analysts or designers, it is easy just to limit user choices to a few as possible to send them down a well-defined and perfectly groomed path. But does that answer their question? How many times have you wanted to say “Siri – lead the way to a great evening with my friends!”. The response from Siri is, “I’m sorry I don’t’ understand what you are asking”.

There are a thousand paths to getting or achieving something. No matter how hard you try to make it simple, it just winds up being even more complicated. Or worse the real thing you need is hidden somewhere because someone felt it wasn’t’ important enough to warrant a button. Some of the best interfaces look very simple on the front end and have a rich set of commands just slightly inside of the interface. As a business analyst and designer, we need to give our users or community a rich experience with our application. Are we the illusionist – forcing users down only one path? Our accounting system has several ways in which to generate an invoice. From a customer contact screen, main menu, sidebar and I’m sure more options remain hidden in the accounting interface. As I watched the finance, customer service, and sales people utilize the user interface with the simple task of generating an invoice, I noticed something important. Not everyone went about taking the same path.

Sales people always went to look at the customer inquiry screen first before generating an invoice. Individuals and their contact information were more important to them, and they would update it before moving on to creating an invoice. Customer service created invoices from the order screens as they were more focused on shipping products. Finance folks just clicked on the main menu option.

Know your users. They each have a story and a way of performing tasks that make sense to them. Think about their “persona” and what they need to accomplish. There is no single path to creating an invoice. Develop a list of capabilities and make sure they are not “hidden” from view. If it all doesn’t fit on a screen, find ways to expand the options for display when requested. Don’t fear including two buttons “Create Invoice” and “Add Invoice” which go to the same screen if it makes more sense to a broader audience of users. It is more about clarity for your users then consistency in terms.

What has a dinner in the park taught me? Smartphones are not as smart as we think they are. Everyone thinks they have choices, but don’t always see the most obvious choice because the choice is not presented in a way the user would understand. Question the choices presented and determine if they are the only choices.

Yes, I still miss my green screen terminal. CMD-1 key forever will mean “useless” help, and a blinking green bar on a black screen will always be a symbol of the endless possibilities to mistype ridiculously long string of text that doesn't make sense to anyone. And that huge 3-ring binder filled with commands-a-plenty works damn good propping the door open.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

Pablo Picasso and Scope Visualization

Paul Crosby — Wed, 07 Sep 2016 14:28:00 GMT

Scope – the last frontier. We are on a mission where no business analyst has gone before. To explore strange new diagrams and to have the project scope clearly understood. Extra credit to those who remember which TV show that was from! Scope and context are the number one reason business expectations about a project are not met, and projects fail.

Let’s face the reality. Projects today are more complicated. In this integrated and connected world of systems long gone are the days of the quick and easy change. Our organization’s architectural diagrams look like the tombs of Egyptian Pharaohs. Symbols and shapes connected by lines that fill the wall of an entire room. Even trying to explain the diagram to someone can take days.

Projects now require more involvement by more people. Our systems and processes are so complex and integrated it’s too difficult for one individual to understand them all. Stakeholders are flung across the globe speaking many different languages. Top it off with organization’s taking on hundreds of projects at the same time. Keeping track of each project’s scope and impacts to the organization are difficult to comprehend. It’s no wonder why understanding the context of a project’s scope is the number one reason why projects fail to deliver value. They lose sight of the project's vision and goals in our complex systems and processes. Everyone is one a different page. We wind up spending a lot of time trying to get stakeholders, sponsors, and team members to have a clear understanding of scope.

So it’s no wonder that scope and context are the number one reasons projects fail. How can you get an entire project team moving in the right direction? Not understanding the scope and context of a project leads to all sorts of time being spent on just figuring out what we are trying to accomplish with a project.

So how do we get everyone on the same page? By that, I mean the same page in the same book!

It’s time to visualize scope. Scope places the boundaries around where the entire project team will work. Bust out that context diagram. Getting a clear common understanding of scope and business expectations leads to better projects that deliver real value. Is that user story a complete representation of the project boundaries or scope? Maybe not. The EPIC or a bunch of user stories combined would be closer to the bulls-eye. A picture is worth a thousand words. Visualization of scope is worth its weight in platinum as it creates the vehicle to ensure a common understanding of the project scope.

Scope visualization isn’t just about a context diagram. That’s certainly a great tool, and I blogged about it previously. Don’t get me wrong – I love my context diagrams. Pushing the envelope a bit, I have used infographics to display project scope in place of context diagrams. In a recent server upgrade project, I was updating the operating systems and consolidating over 1,300 servers. Sticking 1,300 servers on a diagram was an exercise in futility. There just isn’t a big enough piece of paper to display them all. So I pictured things at a higher level. I presented each server farm as a farm – yup cows and red barn with Farmer Joe. The size of the farm was based on the number of servers on that farm. Server farms were in specific locations, so this gave the project team a visual representation of which sites were going to be impacted more heavily. All of this was based on estimates from doing a high-level scan. Remember context is high level.

In each barn was an icon that represented a group of servers. There were three groups: leave it alone, upgrade it and consolidate then retire it. I didn’t have exact numbers or server names at this point, but I knew the servers would be divided into those groups by talking with stakeholders. Servers were put into groups based on our best guess.

In the kickoff meeting, this was a great tool. Sponsor and stakeholders understood in the scope of the project. Yes, they wanted to know more. Everyone wants to know the details, but we were just starting out. Everyone walked out of the room with a pretty good understanding of the scope and estimated size. Many were surprised at the volume of servers in each farm. Overall the infographic did an excellent job of setting the stage for the project visually. All on one PowerPoint slide.

The idea of scope visualization is to present a single page to provide a high-level overview of the changes the project will make to systems, processes, and people. That’s no easy task. Taking the complex and making it simple is powerful. It creates a better shared understanding of the project.

The business wanted a global CRM solution, but all they got were pigeons and index cards. Yeah, that is why context is important.

Context doesn’t just talk about scope – it also sets business expectations about the outcome of the project. It’s important that all throughout the project to keep the communication channels open on what is happening with the scope and how the design is being implemented to meet the scope.

I take the concept of the context diagram a little farther than how most folks typically use a context diagram. You know me always pushing the envelope. Context diagrams usually explain the end state or the outcome of the project. They show the scope of a project outcome.

Building on a good thing, I like to build a context diagram of the current environment at a high level. Even at a high level, I’m often surprised at how differently stakeholders, sponsors, and team members view the current state. It’s a great tool to get everyone on the same page for the starting point. Having everyone on a different page for what we currently have will cause a few issues down the road in understanding the final destination. Knowing where you are starting from is a powerful thing when to explain where you want to end up in the future state.

Taking this concept even a bit further (and perhaps more uncomfortably) into the desired state. Not many projects look at the desire of the stakeholders and sponsors. The desire is stated in the project request form or project charter. The sponsor and stakeholders put together a vision of the expected outcomes in these documents. A context diagram of the project charter or request which elaborates the vision is a powerful thing. It ensures what is being asked for is understood.

Don’t re-invent the wheel. Many times I take the current state diagram and just highlight the areas that are changing. Use color to highlight the add, modify or removes based on the context diagram for the current state. Color visually explains where the changes are visualized to occur.

Now you may think I completely lost my mind at this point. Fear not I’m taking a step even further. I take the context diagram that shows the desired state (based on the project charter or project request) and determines what is feasible. Everybody wants it all but the teleporter to zap you across the globe for a break in Paris hasn’t been built yet. Reality always steps in and dictates what is feasible. Taking the context diagram I will highlight the areas that are NOT feasible. It’s a great way to level set the expectations of the sponsor, stakeholder and project team members.

So when in the project life cycle does all this context stuff happen? Ideally, it should happen before the project starts at a very high level. Wouldn’t it be great to start a project where everyone understood and was in complete agreement about the project outcome? You can bet it would save a lot of time running around trying to get everyone on the same page. Typically, the context is set at the start of the project.

As you move through the project, more and more understanding is acquired. Details need hammering out and there is ALWAYS change to the project. Has anyone ever worked on a project with absolutely zero change? If you have, you are leading a very charmed existence. I’m jealous. Context diagrams can help evaluate how a change would impact the project. So forget about laminating them and hanging them on the wall. They are living breathing documents that will change throughout the life cycle of the project.

The pitfall is that architects and others might expect diagrams that show the smallest of components. Don’t fall into that pit. Your job is to communicate the boundaries clearly but not make it so complicated a rock scientist from NASA can’t figure it out. Detail is important for design but scope context requires things to start at a very high level and be decomposed into more information. Context is simple with enough detail to make it clear.

Break out your inner Pablo Picasso and get creative. Find a way to display context or scope in a visually appealing manner. Color can help bring greater clarity. Highlight areas in different colors to bring focus to them. If a system is risky or substantially impacted by the project scope, highlighting is a technique to denote that risk. Black & White isn’t your friend. Studies have shown that color diagrams – even with a small amount of color – are more memorable.

Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today. Bob the BA offers the Badass BA workshop and Enterprise Analysis workshop which covers this technique in more detail.

8 Ways to Be a Badass Business Analyst Employee

Paul Crosby — Wed, 07 Sep 2016 14:23:00 GMT

Being a badass isn’t about intimidation or trying to be something you simply are not. It’s about knowing who you are and using your strengths to drive forward. So let’s look at a few of the ways to be a badass in business:

1. Passion for Your Craft Is a Powerful and Infectious Energy

Showing passion for your work in always willing to learn more and explore new ideas in your profession shows you are a badass. A badass isn’t afraid to learn something new about their craft. Always be willing to step up to the plate and show what they are good at performing. Sitting back and doing just the expected is not the badass way. If you are amazing at drawing diagrams, then use them frequently in your work.

A few years ago I was managing several projects. Things were not going all that well on these projects, and I knew something needed to be done to get them on track. Holding up the schedule and pointing at it wasn’t solving the problems we were facing. I decided to explore different approaches and ideas by contacting others outside the company for their advice and doing a little reading up on handling scope problems in projects. I learned a lot of scope management techniques as a result of that exercise and was able to apply them to my project. My boss at the time noticed I went out of my way to figure out new approaches, and I was fearless in learning new techniques about my craft. By learning and stepping out to explore new ideas I was able to move the project forward and save the project from failure.

2. Keep Positive

Nobody likes a negative person constantly interrupting, jumping to conclusions and always complaining. Keep a “we can do this” mentality even in the toughest of times. The measure of a badass is in being able to be calm, think clearly and project positive possibilities. When the whole world is crashing down, don’t be the one saying “Well that figures.” Instead be the one saying “This isn’t the greatest situation, but we have some great opportunities here to make positive changes.” See the good in situations where others cannot. Be the person that says “I’ve got a few ideas that might help in this situation, and I would like to bounce a few of them off of you.”

One of the toughest projects I faced was working with remarkable requirements, but a development staff that either didn’t want to or just could not fulfill those requirements with the current system in place. The team quickly got very negative at all the challenges that we were having in development. Everyone’s attitude soured and nothing was getting accomplished. The project was on its way to failure. So I threw a pizza party. My entire team thought I lost my marbles, and it was time to call the men in white coats to pick me up. Pizza does wonders for putting a team in a better mood. I told the team I understood the situation was bad and acknowledged that the company wouldn't accomplish anything without their skill sets. I purposefully turned the conversation from a negative (What is going wrong?) and made it positive (What ideas do you have to make it better?).

This was no easy task. I had to work very hard to move everyone’s attitude toward the positive after months of being in the negative. I was direct in telling them “Nobody wants to work on a negative team – it sucks. What can we do right now to make this team more fun and productive?”. After that hurdle had been cleared, it got easier to involve everyone in making team changes and design changes to the project. I kept telling myself that no matter what happens I will remain positive. The team’s attitude evolved over time. Many team members and company leaders repeatedly said that they could always count on me for being positive and finding solutions to problems.

3. Know Your Craft and Tools

A badass doesn’t just stop learning the basics of their craft or tools. They are constantly expanding their toolset and keep current about their craft. It’s too easy to get comfortable and begin to feel there is nothing more to learn. A badass grabs any opportunity to learn new things.

In my past life, I was at a company where I was pigeon-holed. I did such a good job at data warehousing and reporting that no one wanted to let me try anything new or different. Damn, I was bored out of my mind because every day was the same thing over and over. Sure I was learning new things about data warehousing and reporting, but I never stepped out of that area into other areas. So I forced the issue a bit and shoehorned my way into a call center application. It made sense for me to pursue it because that new system would be feeding the data warehouse. I went a little further than just worrying about data and started moving into user interface design and workflow for the new call center application. It was a great experience to use the knowledge I had in data warehousing and reporting to build better user interfaces and business processes. After the project had been finished, I was seen as being useful in business process as well as data warehousing. The door opened, and I got the chance to work on a whole new set of projects. Don’t be afraid to step out of bounds – you just might be valued for it.

4. Make Life Better for Others

A badass knows that improving the lives of their team members by continuously being focused on improving the way things are done is important. Being innovative to solve problems the team is experiencing in the day to day operations is just as important as solving project problems. Process improvement is powerful. A badass understands it’s not about single glory but helping others to achieve great success.

You always hear “It’s not my job” especially in large companies with well-defined roles. A badass looks for ways to improve the working conditions and tasks their team performs. It can be a simple as creating a library of past project documents that can be reused or finding a new way to perform time reporting that is easier. Whatever it is, a badass is looking for ways to improve processes at every moment and isn’t afraid to suggest well thought out changes.

5. Know Thyself Well

Know thy strengths and know thy weaknesses. A badass is aware of their strengths, and they know their weaknesses and limits. In today’s corporate culture, we focus on weakness. By focusing entirely on weaknesses, performance appraisals have become more like firing squads. A badass knows to play to their strengths and to engage others to help them out with their weaknesses.

There are certain things I have discovered I’m genuinely bad at. Anything that involves molding clay into an object is bound for disaster. Both of my skiing trips ended in an uncomfortable tree hugging. In business I know I’m a driver – be quick, be bright and be gone. It wasn’t until half way through my career that I realized how that impacts others who are not drivers. By understanding how I lead and act, I was able to soften my approach and be more collaborative with others. My driver mentality is a strength that others recognize. I can snow plow through massive amounts of data to give clear direction. I communicate quickly and concisely on projects.

Play to your strengths at all times. If you know you are weak in an area, then go out and find someone who is strong in that area to balance you out. If you get the chance to put teams together, look at each others strengths and weakness to balance them all out. Forget about finding that perfect all around team member without weaknesses. They don’t exist.

6. Don’t Always Say What They Want to Hear

Being a butt kisser or yes man is not the path of a badass. If you are always saying what others want to hear from you, they will never fully trust you because they can’t tell if that’s what you honestly believe or if you are just being a parrot and repeating everything back to them. A badass understands that conflict is part of life, and sometimes you are going to have to say what doesn’t want to be heard.

The trick here is saying it without being annoying or a jerk. If there is an elephant in the room, then say there is an elephant in the room. A badass knows that hiding the obvious doesn’t make it go away but rather gives it greater power. Address it quickly and directly. Forcing the issue is a one-way ticket out the door. Follow the “Toot, Toot and Salute” rule. Bring it up once and if there is no response or disagreement then re-group your thoughts. Bring it up again and if there is still no response or disagreement, then accept it and move forward.

7. Ask Questions, Challenge and Dig Deep

No one likes to be challenged. It puts them on the defensive right away. A badass understands that challenging an idea is an art form and that challenging helps bring deeper understanding and meaning. A badass knows that without asking questions and digging deep, the entire problem cannot be understood fully.

Nobody likes to feel they are being interrogated. Be fearless but considerate in digging deep. Verify your thinking and dig deeper with “Help me understand” questions. Share what you have learned to validate it. Be appreciative of the different perspectives and gather them all up to see the greater picture more clearly. The most significant problems I created for myself was making assumptions and never validating those assumptions. You may not be able to validate or challenge at that specific moment. Write it down, reflect on it and determine if you need to challenge it. Challenge appropriately and thoughtfully. Step back and schedule a challenge at a later time.

8. Lead Even When Your Job Title Doesn’t Say Leader

A badass leads even when it isn’t in their title or role. They had the initiative and don’t shy away from leading in their craft. They don’t wait for someone else to schedule the requirements meetings, they step up to the plate and schedule them.

In the many times, I have played the role of the business analyst I’ve stepped outside my role a bit. I’m probably more comfortable with that then other business analysts in that I have been a project manager. My favorite is when I’m told how long it will take to gather requirements. You know those meetings were without being consulted the project manager has decided how long you as the business analyst will take to gather requirements and complete the design. When I’m in the business analyst role, I often will put together a requirements work plan outlining the steps that will be taken to elicit requirements and build the design. I review it with my stakeholders, project team and sponsors. This runs face first into the project managers desire to create and control the schedule. By gaining common agreement on tasks for the requirements and design process, the schedule can be more reasonably created which in turn helps the project keep to its timeline and budget. Is there a negotiation? Oh yeah – there will be lots of negotiation with the project manager, sponsors, and stakeholders on what will be done and what won’t be done. Step up to leading the task and schedule you will be expected to adhere to for the project.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

Applying design thinking makes us better business analysts

Katarzyna — Tue, 30 Aug 2016 20:42:00 GMT

The International Institute of Business Analysis defines in its “Business Analysis Body of Knowledge” (BABoK) that business analysis is “the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders”. To fulfil this task to a good standard business analysts require, among others, well-developed analytical and problem solving competencies. We all know that solutions we, business analysts, recommend to our organizations can stay within those organizations for quite a while. BABoK, in “The Underlying Competencies” chapter, provides a description of the behaviors, characteristics, knowledge and personal qualities that support the practice of business analysis. This chapter stresses the importance, among other aspects, of analytical thinking. However, is relying on analytical thinking sufficient to provide organizations with sustainable solutions?

Is analytical thinking the most important skill for business analysts?

On the one hand, the job title covers it all, you might say: business analysts must possess strong analytical capabilities; analytical capabilities that include the process of gathering information relevant to the business situation under investigation and identifying key issues related to this information. It also requires the business analyst to compare data from different sources/stakeholders, identify possible cause and effect patterns, and draw conclusions from these datasets to arrive at appropriate solutions. Analytical thinking is, in other words, a process of logical reasoning that converges on one “correct” answer based on the facts we discovered in our analysis. It can be compared with finding the answer to a question: what is one plus one? The correct answer is: two.

On the other hand, the world is changing at a rapid pace. The VansonBourne report, “The IT Complexity Challenge”, from October 2015, concludes that organizations have an increasingly difficult task trying to keep up with the introduction of new technologies and services as well as maintaining existing ones to a high standard to maximize the value gained. These changes in organizations are characterized by high complexity levels and are difficult to solve for many reasons: incomplete or contradictory requirements, the number of stakeholders and opinions involved, and the interconnected nature of these problems with other problems that exist in the organization. These problems are also referred to as “wicked”.

The definition states that wicked problems are ill formulated where information is confusing, where there are many clients and decision makers with conflicting values. Solutions to these problems are not right or wrong, they are simply “better”, “worse”, “good enough” or “not good enough”. The acceptance of solutions lies in the hands of stakeholders and their values and perspectives on how the solution should work/look like. We, business analysts, have to deal with wicked problems on a regular basis, don’t we?

Wicked problems vs analytical skills

In this complex landscape of wicked problems it may not be enough for a business analyst to rely solely on his/her analytical skills to provide satisfactory solutions to organizational challenges. The traditional analytical thinking may be inefficient due to the cumbersome process of gathering information, incomplete and contradictory datasets, hidden agendas of stakeholders and other social aspects of the situation. Alternative approaches may be required

Stepping out of the comfort zone: introducing design thinking

Design thinking isn’t anything new; it has been used for years, as already mentioned in the previous blog. However, the applications of design thinking have evolved over the last couple of years and its usage has expanded to business, in the broad meaning of the word. It has proven to be suitable to provide satisfactory solutions to the “wicked” problems we mentioned earlier. Design thinking is characterized by a recognition of the importance of good understanding the problem to be solved; a deep sensitivity to what stakeholders really want and, more importantly, what they choose to do in day to day life; a willingness to experiment, learn and refine; a focus on whole systems, not just on their parts.

To achieve that, design thinking employs concepts of divergent and convergent thinking, prototyping and iterations to problem solving. Through fostering curiosity, a holistic approach to business situations and focussing on stakeholders, the business situation is explored. This is required to develop a better understanding of current reality. Hypotheses are created that could work in an effort to find one that fits the problem situation. The divergent thinking intervenes with convergent thinking, narrowing these possible solutions down to some candidate solutions, which are further prototyped and evaluated. In this iterative way the best suitable solution is defined.

Design thinking lies close to our human “problem solving” nature. In the 80’s the Microelectronics and Computer Technology Corporation (MCC) looked into how people solve problems. The results are presented in the figure below:

Figure 1: Pattern of cognitive activity – the “jagged” line [source: http://cognexusgroup.com/]

The red line represents a linear approach from our work instructions or process descriptions, which prescribe how we should tackle a problem situation. The green line shows how people really work. The lines differ quite substantially, don’t they? This experiment showed that, faced with a novel and complex problem, people do not simply start by gathering and analyzing data about the problem. Cognition does not naturally form a pure, complete and abstract understanding of “the problem”. It simply does not work that way. It also illustrates that problem understanding can only come from creating possible solutions and considering how they might work. These possible solutions trigger more questions about the problem and strengthen the need to understand what is really needed. This experiment supports the success of design thinking where exploration, ideation, iterations and prototyping help provide value to stakeholders. It is more in line with our human nature.

Applying design thinking makes us better business analysts

Design thinking and its techniques are very much applicable to business analysis. We, as business analysts, are quite often “wicked” problem solvers and help our organizations to change and adapt to a fast-paced world. The idea of divergent thinking to explore the problem and ideate many solutions (possible or impossible), and then convergent thinking to select the best solution direction, fits perfectly with what we are doing. Design thinking offers us tools that help us:

(1) deal with stakeholders and their opinions,

(2) validate whether we are on the right track, and

(3) find solutions that delight the stakeholders in the end.

Step into Right Priority

Praveen Udupa — Wed, 08 Jun 2016 10:14:00 GMT

The previous two posts in the Requirements Prioritization series, we discussed the honest difficulty that stakeholders face when asked to simply prioritize requirements, and how to overcome this obstacle by using prioritization parameters. If you have not read these posts, I recommend you read them first here and here.

In this post, let's discuss some of the requirements prioritization best practices. I will attempt to organize these best practices based on when these will be applied during requirements engineering journey. So here goes...

Requirements Planning Stage

Determine the Stakeholders: Discuss with the Sponsor and other key stakeholders to determine a cohesive set of stakeholders who will participate in the prioritization exercise. Remember that it is totally possible (and acceptable) that more stakeholders might be added to this set. This information will straight away be updated to your RACI matrix.
Tell 'em how it's done: Right at the beginning of your project, when you create (or tailor) your Requirements Management Plan, socialize your prioritization plan (among others) with the stakeholders. Help them clearly ‘get’: the Prioritization Process (we will discuss the process in detail later in this post), the Prioritization Parameters (i.e. the Glasses), their weights, the Rating Scale (all of which we will determine in collaboration with the stakeholders) and the Frequency of prioritization. You may use a spreadsheet (download) to facilitate this discussion and the prioritization exercise.

Prioritization Parameters: Present your recommendations to the stakeholders on the Prioritization Parameters that makes sense for your project. Explain to them what each parameter means, and more importantly, why you think they are relevant to your project. Ensure you achieve consensus among stakeholders and have their approval.
Parameter Weights: Not every prioritization parameter will matter equally to the stakeholders. For instance, most stakeholders will want Business Value to matter more than, say, Implementation Difficulty; thus Business Value is assigned more weight than Implementation Difficulty. There is no limit to the number of parameters, although more the parameters, higher the time required for prioritization. Optimally, 5 or 6 is a good number.
Rating Scale: MoSCoW (Must, Should, Could and Wont) is a popular rating scale. You could chose a HML (High, Medium, Low) or a vH-HML-vL (v stands for very). I personally would use a numerical scale, say a 1-5 or a 1-10 scale. This provides more flexibility in assigning minor variations in priority. Even if you use a non-numerical scale, like MoSCoW, you must assign a numerical value to M, S, C and W. This is to ensure you can calculate the weighted average and derive the overall Priority (see spreadsheet)

Remember, while walking the stakeholders through the above, your tone and tenor of presentation is to ‘collaborate’, and not ‘dictate’. You must be open to customize any aspect of prioritization – stakeholders involved, prioritization process, parameters, weights, rating scale, and frequency

Requirements Prioritization Process

Step 1: Schedule a workshop inviting only the relevant stakeholders. Share with them the prioritization spreadsheet in advance. If you are using a requirements management tool, which has built in prioritization capability, provide access to this tool to the stakeholders. This helps the stakeholders prepare for this workshop (although you should not expect all stakeholders to be prepared. In they are, it is a bonus!)

Step 2: At the beginning of the workshop, ensure that all stakeholders are aware of the prioritization plan (described to them during the requirements planning stage). If not, repeat the plan and ensure all stakeholders are on the same page.

Step 3: Focus the stakeholders on the requirements being prioritized. Typically, prioritization workshop follows requirements sign-off workshop. You would therefore assume that the stakeholders already have an uniform understanding of the requirements. However, at this point, it is a best practice to ensure that there are uniformly understood by all stakeholders.

Step 4: Direct the stakeholders to the first prioritization parameter. Have them go through every requirement and provide their individual rating based on the first prioritization parameter.

Step 5: Once everyone completes Step 4, consolidate the ratings from all stakeholders and derive the average rating for each requirement. Request the stakeholders to review the average rating, and compare it against their own individual rating. If there is too much deviation, request them to surface their concerns. Facilitate an open and free discussion, and forge consensus among all stakeholders.

Step 6: Move on to the next parameter, and repeat Steps 4 and 5 until all the parameters are covered.

Step 7: Derive the overall priority. Ensure that all stakeholders approve the priority.

That’s it…you are done. You may repeat the prioritization exercise as many times as you wish during the project. In fact, projects following Agile methodology require that the user needs are continuously prioritized.

Conclusion

In this three-part series on requirements prioritization, we discussed why stakeholders find it difficult to prioritize requirements, what you can do as a Business Analyst to help them and how exactly you would go about helping them.

Let me know your views and feedback.

Modeling your way to a great backlog

Candase Hokanson — Tue, 31 May 2016 12:24:00 GMT

If you’re a business analyst whose company recently made the move to agile, you may be wondering where you fit in when there is no business analyst role. Or maybe you made the move to be an agile business analyst or product owner but don’t know how your traditional business analyst skills figure into this new agile world. Well the good news is that even in agile frameworks with no official business analyst role, business analysis still needs to be performed for every product so that we know we’re building the right thing. It may be called something else and we may do it differently, but it is still a vital part of the agile process.

With this post, I want to talk about one piece of business analysis - visual modeling - and how it fits into agile and building a great backlog. In waterfall projects, the business analyst will typically gather all the requirements up front (prior to design and development) utilizing visual models to enhance and give context to her requirements. In agile, we do everything with “just enough” detail, “just in time” for the development team to start working on a given requirement or user story, so many people have taken the route that the user story along with conversation is enough and we don’t need visual models anymore. This couldn’t be more wrong! Especially with so many large, global companies moving to agile and having distributed team with lots of dependencies, visual models can help bridge communication gaps that co-located agile teams can cover with conversation.

So, why visual models in agile? Visual models arguably are even more important in agile projects than in waterfall projects because there is a low cost to build or change them. They are easy tools to use to gain understanding between the business stakeholders and the development team without having to spend a lot of time writing requirements or user stories. Additionally, visual models allow the product owner or business analyst to view the whole product and vision while focusing on a sub-set for delivery - enabling the product owner to deliver the most value the soonest. Visual models are a great supplement to the backlog and user stories to gain a richer understanding of the product and the needs of the users. They also help the product owner or business analyst find missing stories and acceptance criteria.

Which models are best in an agile process? We have 22 visual models in RML®, but not all of those are useful all the time, especially on an agile project. However, I’ve found that there are about 5 models that are used on almost every agile project I’ve worked on. Let’s walk through each one - in this blog post, I’m just going to give an overview of each visual model, but you can find more information in the links below.

Business Objectives Model: The business objectives model tells the team why they are working on a project or building a product. It is similar to a product vision, but gives concrete objectives that we want to solve with the project/product. On agile projects, this is probably the most important model because the product owner or business analyst should be tracing every single user story back to the business objectives model to ensure that we are only building what is needed and useful to the user.

Process Flow: Process flows detail out a business process from the user’s perspective. They can be at multiple levels (typically L1, L2 and L3 - starting at the highest, most-abstract level and working down in detail) and so are great for agile projects! At the beginning of a project, the product owner or business analyst can define the L1, high-level process to identify epics or features, and as iterations progress, can dig deeper into L2 and L3 detailed process flows. Each step in a lower level process flow is likely to be one or more user stories.

Feature Tree: A feature tree is a visual model that lists out all features for a product/project in a hierarchical tree format. In agile, this is a good tool to keep up with requested features because it is easy to update. By color coding or making important features closer to the “trunk” of the feature tree, you can easily show iterations or releases.

Business Data Diagram: The business data diagram shows all data objects in a project or product and how they relate to each other. On agile projects, this serves two purposes: as a catalog of the overall data needs (hard to show in a user story) for use in building databases and as a source of acceptance criteria to enforce the relationships between data objects. This is a lower level model and may be started in a sprint 0, but would need to be kept updated in subsequent sprints.

Decision Tree or Decision Table: Finally, decision trees and decision tables detail out system logic and how the system should respond to various input decisions. These can be used to expand a given user story with decision logic or can be used as the acceptance criteria themselves. Since one of the most common ways of writing acceptance criteria is the “Given, When, Then” format, this lines up nicely to decision tables, where the “given” is a precondition, the “when” is a trigger or decision and the “then” is the outcome. Decision tables ensure that every combination of decisions and outcomes is considered, so when using these for acceptance criteria it is clear to the developers and testers what should happen in every instance.

These are the visual models I’ve found useful on my agile projects, which ones do you use?

Glasses for Priority

Praveen Udupa — Thu, 19 May 2016 04:16:00 GMT

In my previous blog post titled "All requirements are important!",

I reasoned that stakeholders only appear to be uncooperative in the prioritization process. In reality, they are unable to prioritize requirements because they cannot see one requirement more or less important than the other.
I urged you to ponder whether it could be due to BA's drawback that s/he is unable to get the stakeholders to really see priority among requirements.

In this post, let us consider a few 'glasses', which will enable the stakeholders to see the relative importance among requirements. Here you go:

Glass #1: Business Value

Business Value is viewed in terms of faster, better and cheaper. Wearing the Business Value glasses, the stakeholders determine the degree to which one requirement contributes to the business to become faster and/or better and/or cheaper relative to the other requirements. Higher the business value offered by a requirement, higher its priority. Typically, business stakeholders weigh in on determining the Business Value of requirements.

Glass #2: Business Risk

Business Risk is viewed in terms of what can go wrong in the business. This must not be confused with what can go wrong to the system (that is implementation difficulty or technical risk). For e.g. introducing an interface between two systems will lead to a bunch of data entry operators losing their jobs. This is a risk although its impact depends on the risk appetite of the organization.

Wearing the Business Risk glasses, the stakeholders determine the degree of risk that the business would face because of a requirement relative to the other requirements. In other words, if that requirement was dropped, then the risk to the business is reduced.

Applying the general principle of fail early, fail quick when the cost of failure is low, higher the business risk posed by a requirement, higher its priority. However, this depends on the organization's risk appetite. Some organizations may choose to do the opposite. Typically, business stakeholders weigh in on determining the Business Risk posed by requirements.

Glass #3: Technical Risk

Technical Risk is viewed in terms of what can technologically go wrong during the implementation of the solution. Wearing the Technical Risk glasses, stakeholders determine the degree of technological risk posed by a requirement relative to other requirements.

Again, based on the general principle of fail early, fail quick, higher the technical risk posed by a requirement, higher its priority regardless of the risk appetite of the organization. Typically, implementation stakeholders like architects, designers and developers weigh in on determining the Technical Risk posed by requirements

Glass #4: Implementation Difficulty

Implementation difficulty is used when demonstrating quick success is important. In such situations, implementation stakeholders determine those requirements that are easiest to implement relative to other requirements. Lower the implementation difficulty of a requirement, higher its priority

Glass #5: Minimum Viable Product (MVP)

MVP is used to determine those requirements without which the product would simply be incomplete. You wouldn't purchase a car without breaks or mirrors for instance, would you? But you might consider buying the car without, for instance, automatic windows.

Thus MVP Requirements must have higher priority over other requirements. In this context, requirements that cater to a regulation must be a part of MVP.

Glass #6: Dependent Requirements

A requirement that by itself may not be treated as high priority, but if other high priority requirements are dependent on this requirement, then it is also provided high priority.

The above are some of the key glasses that can help stakeholders get over their "all requirements are important" syndrome and truly participate in the prioritization exercise. By the way, I am sure you realize that I only use the term "glasses" to extend the analogy from my previous blog. The proper term for glasses is "Prioritization Criterion or Parameter"

Are these the only glasses/parameters that you must use? No, absolutely not. In fact, some of the above parameters may not even apply in your project situation. You may find it necessary to use entirely different set of parameters. As a BA, you must first collaborate with the stakeholders must arrive at a set of prioritization parameters that are relevant to your specific project situation.

In my next blog, I will write a detailed note on the best practice process for requirements prioritization. Till then, I would love to read and respond to your comments...keep them coming!

Stakeholder Requirement: Clarified

Praveen Udupa — Fri, 06 May 2016 10:54:00 GMT

This is in continuation of my earlier post on Business Requirement. If you have not read that post, I recommend you take a few minutes to study that first before continuing with this post.

In this post, let's discuss Stakeholder Requirement. Some people refer to this as User Requirement, but BABOK's nomenclature is Stakeholder Requirement. Understandably so, because a User (i.e. End User of the solution) is just one type of a Stakeholder. Other Stakeholders, not necessarily Users of the solution, may also have needs that they need satisfied by the solution.

Stakeholder Requirement describes how a given stakeholder would like to interact with the solution, in the context of a business requirement.

Let's observe a few points from the above definition of a Stakeholder Requirement:

1. We already know that Business Requirements must not include the solution. We have discussed this in my previous post. But while defining Stakeholder Requirements, the solution approach must be selected. How else would the stakeholders describe how they would like to interact with the solution?

2. If the solution approach changes, the Stakeholder Requirements also change (but the Business Requirements do not change)

3. In the hierarchy of Requirements, Business Requirements are at the top, immediately followed by Stakeholder Requirements. Every Business Requirement gets decomposed into its constituent Stakeholder Requirements. Stated the other way, one or more Stakeholder Requirements trace into one Business Requirement.

4. Stakeholder Requirements are not at a level of detail for the implementation team to design and develop the solution.

Let’s take an example to understand this better. In my previous post, we had discussed the example of an Insurance Company whose Business Requirement was Ability To Collect Premium Remotely. In order to meet this Business Requirement, there are several solutions possible:

First obvious solution: enable internet and mobile payment
Enable direct debit from the customer’s bank account
Partner with one or more banks and enable the banks to collect the premium
Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
Establish several satellite premium collection centers

Suppose we select the internet solution, i.e. the insurance company builds a website where customers make premium payments. The following would be some of the Stakeholder Requirements:

Customer: Ability for a Customer to view a list of all policies where premium is due

Customer: Ability for a Customer to make a payment for policy where premium is due

Admin: Ability for the Admin to update the list of policies where premium is due for all customers

Stakeholder Requirements form the basis for defining Solution Requirements. One might ask why bother defining Stakeholder Requirements at all, if it is not useful for the implementation team to design the solution. The reason is simple: A top down structured approach will ensure that the requirements coverage is close to 100%, and the probability of missing out on requirements is very low. Besides this, this approach helps minimize scope creep. I will write more about this in subsequent blogs.

Business Requirement: Clarified

Praveen Udupa — Fri, 06 May 2016 09:38:00 GMT

"Business Requirement" is a maligned phrase. Different people have different interpretations for what it means. The worst interpretation that I have come across is, “hey, if the requirement comes from a business stakeholder, then it is a business requirement”. Requirement from business is NOT business requirement. For God's sake, every requirement comes from a stakeholder, otherwise it is not a requirement.

In this blog, I wish to clarify what exactly is a business requirement. I base this entirely on the best practice definitions documented in the BABOK v2 (and v3…truth rarely changes!)

Let’s take a short case:

Assume there is an insurance company that is dealing with a sticky business problem: they have a significant proportion of the policies lapsing by the first anniversary. In other words, the customers who buy an insurance policy today do not renew it the following year and, instead, let the policy lapse. Upon performing root cause analysis, the insurance company determines that the customers do not care to renew their policy because they don’t like to travel all the way to the branch office to pay the premium in order to renew their policy. In fact, they find commuting to the branch office so troublesome that they find it acceptable to let their policy lapse.

Now, what does this insurance company need to deal with the policy lapsing problem?

The insurance company requires an Ability To Collect Premium Remotely. This is a business requirement.

According to the BABOK, a business requirement is simply a statement of goal, objective or outcome of why a change is initiated. (Please see my P.S. at the end of this article)

Let’s take a closer look at the above business requirement:

Business Requirement exists in the Problem Domain. It captures the need of the business in order to eliminate a problem (actually the symptom). If the insurance company develops the ability to collect premium remotely, then, according to the root cause analysis, more customers will be willing to renew their policies, and consequently the lapse rate will decline.
Business Requirement MUST NOT capture how it will be met, i.e. the statement of business requirement must not include the solution. This is important. Very important. Well, why is this so? There are a couple of reasons:
1. First: Business requirements are developed during Enterprise Analysis (BABOK v2) or Strategy Analysis (v3). To be more specific, they are developed after assessing current state of the organization. At this point in time, no one even know what the solution is because it is not yet identified. Hence the question of including the solution in the statement of business requirement does not even arise.
2. Second: there always are multiple potential solutions that can be employed to meet a business requirement. If the statement of business requirement includes a solution, one would tie the organization to the said solution without considering any of the other solutions. In the above insurance company example, there are several solutions possible:
  - First obvious solution: enable internet and mobile payment
  - Enable direct debit from the customer’s bank account
  - Partner with one or more banks and enable the banks to collect the premium
  - Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
  - Establish several satellite premium collection centres

As you can see, any one or more of the above solutions will provide the remote premium collection ability to the insurance company. Thus, it is not prudent to include the solution in the statement of business requirement.

Most people whose role/designation is Business Analyst operate in the IT space. They define the requirements for an IT solution. More often than not, these BAs do not get to define the business requirements because they mostly never participate in Strategy Analysis projects. However, every BA participating in defining the User and Solution requirements MUST begin by understanding the Business Requirements.

More on this in my subsequent blogs...but for now, I will look forward to your comments!

P.S:

BABOK is probably confusing for a first time reader (even if this first time reader is a seasoned BA). The BABOK makes a confusing statement - it says business requirements are high level statements of goals. This seems incorrect because a goal and requirement are clearly two different things. Here is how I reconcile various terms:

First comes Business Strategy
Business Goals are defined from Business Strategy
Business Objectives are SMARTly decomposed from Business Goals
Business Requirements are high level statements of goals (not Business Goals) in order to eliminate a Problem that is preventing the org from meeting its Objectives, without including any indication of the Solution in its statement
Stakeholder Requirements (or User Requirements) are needs of Stakeholders from the selected Solution, in the context of a Business Requirement
Solution Requirements define the behavior of and constraints imposed on the Solution in order to deliver the Stakeholder Requirements

The most important question for a Business Analyst

Praveen Udupa — Sun, 01 May 2016 14:57:00 GMT

Years ago, I was consulting as a Principal Business Analyst for the second largest company in the world in the money transfer business. One fine morning, I was engrossed in my work when my business stakeholder, (let's call him Tom) arrived at my desk.

Tom: Praveen, I have a change request for you. Well, this is a new business requirement.

Me: Oh...a new business requirement! Okay. Sure..let's hear it.

Tom: You know the search screen that we have (see below). I want to change it.

Me: Okay...

Tom: Essentially, I want you to remove all the search criteria fields, and replace them with just two fields...one, a drop down and the other a text field. The drop down will have the same values as the current search criteria. The Agent (i.e. the User) should first select the search criterion from the drop down, and then enter the search value in the text field.

Me: So, the new screen should look like this, ha?

Tom: Exactly!

Now, here is a question for you. Pause reading this article for a minute and ponder over what you would do at this point if you were me. Here are some options:

Update the Search Transaction use case to reflect the change and pass it over to the design team for implementation
Ask Tom to meet the PM and follow the change control process
This seems like such a simple change...there is no change to the actual search function, just some UI modification...so circumvent the change control process and just get it done
Perform a detailed impact analysis and figure out all other functionality that might be impacted because of this change.
None of the above

What would you do? Which option would you opt for?

Sounds like option 4 would be the most logical path to take.

However, if you chose option 5, you would be right. I didn't choose any of options 1 thru 4 either.

What I did was to ask the most important question that a BA must ask -WHY.

Me: Tom, this is a simple change no doubt. If you could humor me for a couple of minutes, I would really like to know why you need this change? What is happening in the business that triggered you to bring this change request?

Tom: Here is the issue Praveen. You see, when a customer intends to make a money transfer transaction, she first logs on to our website. She then creates a Send Transaction where she enters all the details, i.e. the sender details, the receiver details, the amount of money to be transferred, etc. Once she enters all these details, she saves the transaction.

Me: Okay...got it!

Tom: Then, she takes the actual cash and heads to one of our Agent location. The Agent has access to a money transfer terminal. The Agent asks for her name to pull up the saved transaction on his terminal. The customer states her first name. Now the Agent types in her name in the Last Name field. The transaction is not found. The Agent asks her name again, makes a mistake...and can't find the transaction. The customer is irritated, and she goes out straight to our competitor.

Me: Oh vow!

Tom: That is why I want this change. I want to make sure that the Agent actually asks the customer whether she is stating is her first name, last name or something else. That is why the drop down field. I want to make sure that the Agent is able to pull up the transaction in the first attempt.

Now, my dear reader...think about this real business problem and then look at the "business requirement" that Tom has brought to me. What can you observe?

Did you get it? Exactly...you got it!

One, Tom has actually brought you his perceived solution and has disguised it as a business requirement.

Two, the solution that Tom has brought will definitely NOT solve his business problem. How can having a drop down box eliminate the possibility of making mistakes on the search screen?

Having now understood the real business problem, you can think of several possible solutions:

When the customer saves the transaction, let's create a unique ID. Instead of searching for the transaction using name or other criteria, searching using the unique ID is much more robust
Create an intelligent search function, where there is no need for any search criteria label...enter anything - name, SSN or anything else. Make the search function so robust that it searches all saved transactions and pulls up all transactions closely matching the search value and displays the search results sorted by relevance
Etc...etc...

Think about what would have happened had I not asked that 'WHY' question! I would have ended up implementing what Tom wants, and not what Tom needs. After the new search function is released to production, Tom would have very soon realized that the solution is not working at all and his problem still persists. Who Tom would blame then is anybody's guess.

By the way, in my 15+ year career as a BA, I have noticed several BAs not asking this WHY question. This is why I suspect these BAs become infamous in their team as "just postmen" who add no real value to the project.

I cannot really overemphasize the importance of asking WHY for a BA. A good BA will always understand the true underlying business problem and solve that problem. A good BA will never take any statement from a stakeholder at face value and treat it as a requirement. Remember the 'A' of BA!

P.S. It would be interesting for you to learn that solution #1 above could not be implemented because a competing organization had patented that process! The patent prevented my client from creating any identifier that uniquely identified the transaction. My client therefore had to use one or more pre-existing identifiers to identify the transaction.

Top 10 mistakes in Use Case Modelling

Trividh Patel, CBAP — Mon, 11 Jan 2016 03:10:00 GMT

Use case modelling is the most powerful requirements modelling technique to model solution requirements if applied correctly. I have come across many BA teams (including my own) that made lot of common mistakes in use case modelling. By avoiding the top 10 mistakes identified in this paper, BA teams can not only save lot of efforts in use case modelling but also significantly enhance the value delivered and improve the satisfaction of stakeholders.

1. Naming the actors using the job titles

Job titles and actor names are two different things and often cause confusion. This is because two different users, with different job titles and organizational responsibilities, may have to use the system as a same actor; for example, a supervisor can have access to and use the functionality used by his/her subordinate. Actor is a role that is with respect to the system as opposed to a job title which a role with respect to the organization. Job titles may typically determine user types. Remember, job titles of people may change but the roles they play would remain relatively stable.

2. Creating only the use case diagrams

Use case diagrams only provides summary of the relationship between the actors and the use cases. Can we tell what a system does basis only the use case diagram? No; a system cannot be built just based on the use case diagrams. We need detailed use case descriptions to design and build the system.

3. Not capturing enough details

Too much detail can obscure the flow of the use case and too less can make it really meaningless. “How detailed a use case should be?” In as much detail as possible and in as much detail that is required to make them unambiguous to describe what the system must do. Focus on what is important and continue to add details till all the stakeholders are satisfied.

4. Describing everything a system does in a use case

It is important to identify all the use cases and describe them so that everyone understands who uses the system and what goals they achieve by using it. This is particularly important when the user-system interaction is complex and detailing the system behaviour is essential to develop and test the system. However, if we blindly do this for all the use cases than we are just increasing the documentation and subsequent time required for reviews and sign-off, without delivering any additional value to the project and its stakeholders. So, for cases where the user-system interaction is simple, use cases are not required to be fully described. In such cases, a simple use case description supplemented with declarative requirements and other models may be sufficient to understand what needs to be done.

5. Performing functional decomposition

BA teams typically tend to group functional requirements, or break them in form of functions or menu-items and identify them as use cases. What they don’t understand is, high-level use cases cannot be decomposed into lower-level use cases and also use cases cannot call, communicate, get linked or sequenced with other use cases. This approach is most common of all mistakes made while identifying and describing use cases. Let us try to understand this with an example.

What use cases will you identify for a system say, a car? The adjoining diagram shows the use cases identified using this approach. Here, all the necessary functions (menu-items!) are available to a ‘Car Driver’ (actor) to drive a ‘Car’. With this approach, are we answering what the ‘Car Driver’ will do to drive (actual goal) the ‘Car’? None of the use case actually describes the way ‘Car Driver’ will interact with (or use) the ‘Car’ to drive it without linking or sequencing them. The system appears as a large set of disconnected functions. To identify the right use cases, always keep in mind the goal that the actor wants to achieve by using the system. Each use case must be complete to provide value to at least one of its actors.

6. Writing perfect use cases

There is no such thing as perfect use cases. Many BA teams waste their efforts in trying to create perfect use cases. The focus should be on making use cases as good as required for facilitating communication amongst stakeholders to achieve shared understanding of requirements and moving to system design, development and testing.

7. Detailing use cases with the CRUD behaviour

Although it is not technically wrong but detailing uses cases with CRUD (create, retrieve, update, delete) behaviour, for example maintaining information for administrative systems, is a waste as it is mere repetition of declarative form of requirements specifications. Use cases with the CRUD behaviour don’t add much value to ensure that the system is doing right, particularly when information can be added in any sequence without any dependency. Except for data validation rules and specific fields to be entered, the use cases with the CRUD behaviour become repetitive. These efforts can be used for detailing use cases with real flow of events.

8. Using the use case model to design the system

Many times, BA teams also document how a system should handle certain functionality internally as part of use case descriptions. By specifying such functionality we are imposing constraints on the development team to design the system in a specific way. Many would argue that “it is a BA’s job to think for all scenarios and provide a solution” but we forget that the real purpose of a use case is to describe what system does to fulfil the goals of the actor and by mentioning constraints inside a use case we are just making this behaviour difficult to understand. So, anything that must be handled in a certain way should only be described in the use cases and all other things should be left out for the developers to decide. Constraints can be captured in other specifications and traced back to the use cases so that they are not forgotten during the system design. Use case model must never be used to design the system. Use cases describe what the stakeholders want the system to do and not how the system implements the functionality.

9. Describing things outside scope of system

Use case model captures the interactions of actors and the system and describes what the system does to fulfil actor goals. Outside system boundary a stakeholder (identified as an actor) may interact with another stakeholder (who may be identified as another actor); to support the business process. If this interaction (business process) is not supported by the system, it should not be captured in the use case model. Use cases can be used to capture business processes as “business use cases” with actors outside the business boundary. Never mix systems use cases and business use cases.

10. Misusing the use case relationships

BA teams also spend lot of time structuring the use case model, with use case relationships such as include, extend and generalization, assuming that such structure is required in every use case model or required for the system’s architecture. BA teams typically useinclude relationship to break a use case into smaller use cases by performing functional decomposition of the system. The result is that none of the use cases by themselves provide any real value as it becomes very hard to see what a system does. Using use case relationships without understanding their real purpose just results into a confusing use case model.

About Author

Trividh Patel, CBAP® has well over a decade of experience in an IT services industry, in various functions such as Business Analysis, Business Technology Services, Presales, and Project Management, primarily in Banking, Financial Services, and Insurance domain.

Trividh has done his MBA from JBIMS, University of Mumbai, and Bachelor of Engineering from VJTI, University of Mumbai.

Trividh Patel, CBAP® provides specialized Business Analysis Trainings, such as

1. Fundamentals of Business Analysis
2. Mastering Use Case Modelling
3. CBAP® / CCBA® Certification Prep Course

Trividh Patel can be reached on -
LinkedIn: http://www.linkedin.com/in/trividhpatel

Dealing with Difficult Stakeholders

sbowling999 — Sun, 27 Jul 2014 20:50:00 GMT

The question will undoubtedly arise during your tenure as a business analyst, ‘How do I manage a difficult stakeholder?’

I once encountered a stakeholder, a very highly respected mathematician, who had developed an application based on a mathematical model of his weather systems. The algorithm was amazing. The application sucked. It was my job to:

1. Ensure his model used enterprise data so it could be shared amongst other applications I was helping develop and,

2. To either refactor and debug his application or port his algorithm to a new User Interface so it was available to a larger user group.

Long story short, he hated me. More accurately maybe he hated the idea of me. So what did I do? I elicited his feedback every step of the way. I made him a full partner in the change experience. But I also put my foot down and let him know the change was going to happen. I recognized that he was heavily invested in the application he had grown from scratch. The larger community wasn’t aware of his accomplishment. So I suggested he demo his application to a larger group of users. He got the opportunity to share his vision with the enterprise. People were amazed at the model and he received his just credit and some back slaps. But during the course of the demo he was also slightly embarrassed because there were technical issues and bugs that were apparent (as I knew they would be) which motivated him to embrace the improvement process.

It also helped to understand what was important to him and his own analysis process. Because he was the logical type I crafted my analysis plan to rely more heavily on statistics and fact based decision making. After showing him the error logs for his tool as compared to other applications for example, we agreed together that reducing the instances of error and downtime needed to be our joint #1 priority before we exposed the application to a larger audience. Because I always kept him informed, treated him as my primary stakeholder and never pulled punches, he began to see me more as his partner who could help him through the change process and bring his model to a much larger audience. For that to happen, he had to let go of complete control and we eventually repackaged his model/algorithm into an entirely new UI consistent with our other enterprise applications. Looking back, the only thing I would have done differently is put my foot down on Day 1 instead of Week 3.

It’s also critically important to find out the concerns of your most difficult stakeholder. In another example, I had a difficult stakeholder group who were code enforcement inspectors. You know the guys who condemn houses? As a group they were refusing to use their 2 year old mobile application. Citizen complaints raged as their investigation backlog grew. When their contractor mistakenly demolished the wrong house, the Mayor’s office finally decided to hire me as a consultant to improve their systems and processes. The workers grumbled and pushed back on requests for changes. I decided to select the least tech savvy, most senior vocal influencer and rode with him for a solid week. Every morning at 6 a.m. we met the crew for coffee at McDonalds. I donned work boots and shadowed him as he walked around in dark condemned houses in the worst part of town. We met the guys for lunch at the 7-11, conversed and I truly began to understand their challenges and why they hated the old application. I also understood that the fear of using the technology was elevated due to a general lack of experience with web technology. At the end of the project this ‘difficult stakeholder’ helped me teach the training course and volunteered to be the ‘go to guy’ for all other inspectors! Listening and putting yourself in the stakeholders shoes really works.

So here are my steps to better stakeholder relationships.

Identify key stakeholders who can throw a wrench into your project’s success. Key stakeholders may be members of the executive or management team. They could just as frequently be informal team leaders or members who influence others. Ensure you are proactively nurturing those relationships.
View them and treat them with the importance a key stakeholder deserves. Nothing turns a stakeholder into hostile mode faster than getting a cold reception and the sense that his opinions are not valued.
Take the time to truly understand their perspective and concerns. Put yourself in their shoes. Not only will you be investing in the relationship but you will likely also learn important information that can help craft your analysis, deployment, training or support plans.
Ensure there are ample opportunities for your stakeholders to provide feedback in a setting that is most comfortable to them. Some people aren’t comfortable sharing in a group setting or JAD session.
Be sure to incorporate their feedback into the overall plans so their concerns are addressed.
Recognize that change doesn’t happen overnight. Employ an appropriate change management strategy.
Create opportunities for your difficult stakeholders to show leadership and excellence. Everyone wants to be recognized for their accomplishments.
Engage them to help win the buy-in of other team members who sit on the fence. Nothing ensures your project’s success like having the team leaders champion the change.

The success of a business analyst depends heavily on the relationships he builds along the way. Pay attention to the key stakeholders and remove this obstacle so you can get on with the business at hand.

BABOK v2 - End-to-end data flow diagram analysis can highlight issues

Alan — Thu, 10 Jul 2014 01:20:00 GMT

As part of preparation to sit the IIBA CBAP exam, I wanted a one page summary of the overall BABOK flow. The first step of creating a summary matrix showing a derived master list of documents (e.g. Inputs + Outputs) versus the process that creates or uses it was interesting, but not entirely helpful.

By using the matrix to create an indicative data flow type diagram, that helped to better understand the overall end-to-end process documented in the BABOK.
Note: Clear stakeholder information was not available so a Business Process type Model was not possible.

The data flow type visualization technique is very useful:
1. It is an additional visual means of communicating complex information for people who struggle with understanding just text.
2. It quickly shows the flow of information between the various processes
3. The data flow diagramming conventions help to highlight issues. E.g. No clear sources or uses of specific deliverables, redundant and reverse flows etc.

This is also timely given the review of the Draft BABOK v3 material that has been requested and that closes on July 11th.

5 Pitfalls to Avoid in the Requirements Development Phase

Ken Young — Wed, 07 Aug 2013 17:37:00 GMT

Developing requirements is a process with many moving parts. It involves aligning multiple stakeholders from different areas within an organization to determine what must be developed to fulfill a business need. Because it is a process, there are a number of factors that can cause the process to break down and lead to the development of faulty requirements:

Lack of Clear Objectives: Every application is built to play a role in some larger business context. When the business client is unclear in communicating the purpose of the application, or stakeholders lose sight of the application’s business context, the requirements in all likelihood will “miss the mark”, lacking essential functions and including unnecessary features.
Lack of Stakeholder Involvement: One of the biggest challenges in the requirements process is getting stakeholders to invest their time, over multiple elicitation sessions and then multiple review cycles, to carefully examine the requirements and provide feedback. When stakeholders are inaccessible, or are not invested in the project during the early phases, requirements flaws can remain undetected until after development begins.
Inconsistent Information Gathering: When developing complex applications, a team of business analysts will often be involved in gathering information. When inconsistent elicitation approaches are used to gather and record information, it becomes difficult to categorize, prioritize, and ultimately reconcile the often conflicting needs of different stakeholders.
Information Overload:The traditional reliance on recording requirements in long, unwieldy text-based documents not only leads to misunderstanding, but also contributes to stakeholders’ lack of involvement in the requirements development process. Using long text-based documents makes it hard for end-users and business clients to picture how the application will behave, and what may be missing.
Poor Expression: To review requirements, and ultimately build applications, all stakeholders, from the business client and end-user to the application developer and tester must be provided information in formats and using language that each can understand. Delivering information in forms that don’t take into account the different types of stakeholders inevitably leads to flawed requirements and the development of applications that don’t fulfill the objectives of the business.

When developing requirements, check to ensure that you have avoided the pitfalls above and your requirements are much more likely to be complete and effective.

Ken Young works for Blueprint, The Requirements Company. He can be reached at ken.young@blueprintsys.com.

Applying Agile principles to requirement analysis

Ryan Thomas Hewitt — Mon, 27 May 2013 13:31:00 GMT

Background

The Agile methodology originated within the software development industry. Since its inception in 2001 – Agile has expanded beyond an initial developer-centric community – to being embraced by multi-discipline teams working across numerous industries.

The antecedent of Agile within IT was the Waterfall methodology. The Waterfall framework consisted of a series of sequential, discrete phases – with each phase conveniently mapped to a role/responsibly:

Analysis Phase -> Requirement Analysis (Business Analysts/Product Owners)

Design Phase -> UX (Designers/Usability Experts)

Development Phase -> Software Development (Developers)

Testing Phase -> QA (Manual Testers and Developers in Test)

Delivery Phase -> Release Management (Project Managers)

Due to the increasing popularity of Agile – requirement analysis has been encouraged to transition from being a stand-alone phase owned by BAs/POs – to become a project facet that can incorporate Agile principles.

In what ways can requirement analysis adopt Agile principles?

Collaborative requirement analysis

Prior to Agile – the practice of the development team being presented with an upfront, non-negotiable, detailed requirements document (BRD/functional specification etc) was common. With the advent of Agile – requirement analysis should no longer be restricted to the interaction between BAs/POs and the business – instead we should embrace collaborative requirement analysis:

A popular collaborative requirement technique is the “3 Amigos”. This process involves the developer, BA and QA discussing the requirement specification in a workshop. Each Amigo will offer a unique perspective – through discussions the Amigos will identify edge cases, undefined requirements, opportunities and potential reuse. The 3 Amigos technique can also reduce the risk of incomplete features being pushed into development by the product team – requirement specifications must be pulled into development when they have been reviewed and accepted by the 3 Amigos.

Collaborative requirement analysis facilitates a project-wide sense of ownership – and also communicates a common understanding of what features need to be built. Collaborative requirement analysis produces more robust specifications – and reduces the role-based silos that can exist on projects.

Detail as an emergent property

Agile artefacts such as technical spikes and development iterations mean that high-level requirements can be considered sufficient at project initiation. Low fidelity requirement assets (e.g. user stories /”back of the napkin” designs) should be employed on Agile projects:

Just-in-time requirements analysis (JITRA) has a concept that requirements should only be specified at the level of detail required for upcoming development. JITRA states that the further in advance of development requirements are defined – the more probable that requirements will become out of date, leading to rework and wasted effort.

Detail should emerge when it is required – which is typically towards the middle/end of the project lifecycle. Initial requirement analysis should be focussed on business justification and solution scope.

Embrace change

Specifications will evolve throughout the project lifecycle; all team members must acknowledge the benefit of responding to change. Adapting to changes in circumstances/urgency/understanding is crucial – requirement analysis should be considered an iterative rather than exhaustive process:

In terms of systems theory – project teams should be viewed as open systems. As the system will tend towards a steady state – change should be encouraged and communicated at an organisational level. Regular priority sessions, stakeholder workshops and competitor reviews should be used to mitigate resistance to change.

Incorporating feedback is crucial to the success of a project. Requirements are not unchangeable statements – they only reflect the current and expected situation, both of which are liable to change.

Necessary documentation

The adoption of Agile principles does not mean that requirements should not be documented. Requirement documentation is vital for developers, QA and the business stakeholders:

The principle of living documentation should be embraced. This means that all documentation needs to be accessible and up-to date. Business users, developers and QA should be able to request requirement changes. Documentation is most valuable when it is understandable by all team members, available and responsive to change.

Lightweight documentation such as feature files and high level process maps summarise the output of the requirement analysis process. The Agile methodology encourages appropriate documentation – superfluous detail is wasted effort; Agile does not negate documentation.

Continuous process improvement

Requirement processes should not be viewed as immovable obstacles. Instead these processes should evolve and adapt to meet the needs of the project. Where a process or artefact ceases to produce the expected value –it should be reviewed and changed by a self-organising team:

Retrospectives are a popular technique for identifying improvement opportunities. Team members meet to discuss what the team needs start doing, stop doing, and continue doing. Regular (every 2/3 weeks) and actionable retrospectives provide an open forum for continuous process improvement.

Requirement analysis processes (to-be-analysis, process mapping, stakeholder workshops etc) can always be improved. A technique that is effective for one team – may not be effective for another – or at least may require several modifications.

Continuous delivery

The Agile methodology promotes product iterations and regular releases. In order to align with this ethos, requirement analysis must produce a constant output – a steady flow of requirements will avoid the “big bang” requirement delivery that characterised the Waterfall methodology:

Minimum Viable Product (MVP) provides the scope of requirement analysis. The MVP will be delivered in multiple iterations – requirement analysis must be constantly baselined against the MVP and ensure that there is a sufficient specification available for each delivery.

Shorter delivery timescales encourages more frequent requirement analysis output. Specifications should be aligned to the MVP – features need to be deliverable and contribute to the MVP vision.

Conclusion

Iterative, collaborative Agile development has replaced the sequential Waterfall development methodology. Prior to Agile – the product team could hand over a list of detailed requirements – which would then be used by developers to build the product. In order to align requirement analysis with Agile development practices – the following principles need to be applied: requirementcollaboration, iterative specifications, embracing change, necessary documentation, continuous improvement and continuous delivery. By adopting these principles requirement analysis will transition into the Agile world, produce better specifications and ultimately lead to greater quality products.

Follow-up to “So, you’re buying a package? Don’t forget your business requirements…” Don’t over-analyze!

David Wright — Sat, 09 Feb 2013 02:47:00 GMT

For those of you who do define requirements for their software development projects, but are new to buying packages, a cautionary warning; they are not the same thing. Consider the following “the system shall” requirement statements.

1) The system shall determine if a person ordering pizza is a current customer.

2) The system shall determine if a person ordering pizza is a current customer, only if the person is phoning to place an order.

3) The system shall determine if a person ordering pizza by phone is a current customer using the person’s name and phone number.

Each requirement is at a certain level, increasing in detail from (1) to (2), and from (2) to (3).

- Requirement (1) is at high-level, stating that the system shall do something with certain information.

- Requirement (2) is more detailed, stating that the system shall do something with certain information, in a certain situation.

- Requirement (3) is fully detailed, stating that the system shall do something with certain information, in a certain situation, according to certain rules.

Requirement (3) is what you need to provide to designers/developers to use in new software development. However, this not what you need to provide to vendors when you send them an RFP; in fact, this level of detail can be over-kill analysis and can restrict the number of vendors who could meet your needs. By being very specific about rules and restrictions, you may eliminate a vendor who has a different and possibly better approach to meeting the business need, e.g. a better way to determine who is a current customer.

So what level of detail do you need? High level requirements like (1) can be useful at the start of a project, to describe scope and support planning; this level can also be used in a Request for Information (RFI) sent to vendors, just to get an initial view of what the marketplace looks like.

When you get to an RFP, you need more detail to differentiate vendors better, and Requirement (2) is an example of this level, which I call mid-level or standard-level of detail for requirements. At this level, you can see the difference between vendors in meeting your requirements, enough to evaluate their product and decide which one will serve you best.

So I now have two recommendations for organizations looking to buy a package:

- Don’t forget your business requirements…

- … but don’t over-analyze your needs, so you can best evaluate those packages.

“Why do I need Requirements? I’m buying a Package!”

David Wright — Mon, 31 Dec 2012 02:59:00 GMT

In the wide world of information systems, development of new software receives the most attention from industry writers. Whether it is traditional magazine articles and books, or blog posts, or discussions in groups on LinkedIn and other sites, it is all about “green field” development.

However, when one considers the wider view of organizations concerning information systems, it is common that new software development is not always the primary means of implementing new systems. Organizations do need software for many different functions and data, but a lot of those are common; organizations that realize this do not develop their own software for common needs, they buy it. It actually started a few decades ago with functions like general ledger accounting and human resources, then it moved into more specific domains like insurance or banking, and on into cross-domain ERP packages popularized by major vendors.

When organizations first started to buy more than build, they were often delighted by the time savings: “I can have it now? And not wait 2 years for it to be developed in-house? Where do I sign?” What many organizations did not realize, and their internal IT people probably didn't see either (at first), was that it was only the pure development and system testing activities that were being saved. There was still the need to determine what the package was actually going to do. While software apps provide many common and standard functions, which ones are implemented, and how they are configured still vary significantly based on an organization’s own needs. Ahead of that, the decision has to be made concerning which package to buy in the first place.

This is where business requirements come in. Again, the focus and discussions about requirements these days is primarily about their role in new software development, such that some organizations forget or discount the need for requirements when buying packages… This is a recipe for disaster.

It is true that companies buy things all the time, and often use a standard Request for Proposal (RFP) process. A common process is a good thing, and proposals for quantifiable products such as hardware or components can be straightforward. An RFP for software, however, is specifying an intangible thing that has to perform a function in a specific way. That means defining complete and correct business requirements.

A web search on RFPs or package implementation failures will quickly identify a primary cause; “Failure to clearly define the business requirements for the project”.

(see http://www.orionsecuritysolutions.com/the-o/item/188-request-for-proposal-mistakes).

Even the (in)famous lawsuit between Waste Management Inc. and SAP concerning a failed project included a claim by SAP of Waste Management "failing to timely and accurately define its business requirements" as a contributing reason for the failure.

(see http://www.cio.com/article/486284/10_Famous_ERP_Disasters_Dustups_and_Disappointments).

(For even more on the importance of requirements, see the Business Analysis Benchmark Study from IAG Consulting, see http://www.iag.biz/resources/library/business-analysis-benchmark.html )

So, an organization cannot skip over or pay lip service to business requirements definition in software package projects. Done properly, good business requirements can be used to directly fill the part of an RFP that scares most people: the functionality and data that a package has to meet to be considered for purchase.

When first putting together a list of candidate packages, there may be a lot of vendors who claim to meet your needs based on a summarized description of their products; sending vendors an RFP containing good business requirements will quickly weed out the ones who don’t measure up. Many times, (good) vendors react to this kind of RFP by declining to respond when they see that their product really does not meet the business requirements; this saves both parties time and effort on a deal that would never have gone through.

This will normally lead to a short list of vendors who have a product that could meet the requirements. Getting to one vendor usually involves product demonstrations, on-site trials and other means of evaluation. Of course, other requirements need to be met as well, perhaps technical requirements the software has to meet to run in the desired environment (although hosted and other “cloud” options are changing this). The best scenario is to have two or three vendors whose products will meet the requirements, after which the remaining negotiations can be about getting a good price … all because of having defined the business requirements.

And last but certainly not least, having the business requirements eases the implementation of a package. In decades past, buying a package meant buying code; if alterations to the package were needed, that meant changing code, and getting it to work. This was often difficult and would commonly void any agreement with the vendor to support the package and provide updates.

These days, good packages are built to be configurable. A vendor will often have consultants who can configure the package; and what do those consultants need as input? Your business requirements.

If by chance and very good luck, the project has reached this point without having defined the business requirements, they will have to be defined now if the package is ever going to work properly; and there is a very likely possibility that when the requirements are finally documented, it is clear that the wrong package was purchased. That’s when stories about project failures turn up in industry magazines and sites, and even the regular media if the failure is colossal enough.

So, you’re buying a package? Don’t forget your business requirements…

Feedback cycles, meet deadlines. NOT good bedfellows

theBetterBA — Sat, 08 Dec 2012 20:12:00 GMT

Its quite a feat of strength to pretend you don’t have any weaknesses. I don’t pretend to be that strong.

Its quite a bit easier for me to look for faults, gaps, misses, short comings, imperfections and details that spell out why something is not right.

Its a blessing and a curse.

Looking at my deliverables in this light is second nature to me. Seek out opinions. Get critique. Make your work better. Constantly strive to push yourself.

But how often is that process of seeking critique under as much scrutiny as our work? Is it not as important? The means by which we seek out advice, and how we incorporate it is a corner stone of our work ethic.

It is much further reaching than our current project or task. It becomes part of the mechanism by which we operate. Its how we interact. Its how we present solutions and spread a sense of ownership. Its how we build teams and get stakeholders working together.

Collecting feedback, analyzing risk, determining scope are all facets of our role that we bake it into our projects. Its what makes us Business Analysts, Project Managers and good at our jobs. Its second nature.

(Image referenced from Qualtrics.com)

Until recently, what I have failed to realize about myself is where my “Assumptions & Constraints” are not being considered when I write my own “System Requirements”. Where can I improve? What about me is a risk to the business? How can we neutralize that risk?

For example, a portion of me that is very nearly atrophied since college is the ability and respect needed to accommodate deadlines. What’s the solution? If we can take a look at ourselves, at our weak areas through the lense of a requirements document, we may have immediately obtained that objective view that is necessarily to address a business problem.

Looking through the Requirement Document Lenses at Ourselves:

Analyze ourselves and the situation to define the problem (the Root Cause); ask others for thier throughts too
Identify what success is going to look like (our Business Requirements) when we’re done
Outline how are we going to deliver that success story (our Functional Requirements)
Think through all the places our impact has reaches (use cases)
Add some limits and restrictions we’re likely to encounter when working through our problem (assumptions and constraints).

We could take this to a whole new level, and write out sample requirements – which I may yet do! – but it is enough to employ this objective tool that we use on our projects as a way to address our own business strategies.

How are we going to get where we need to be? What do we need to do to get there? What does success look like?

Going to be asking myself these questions for some time to come.

In the mean while, one of my own business concerns is the need to address my ability to meet deadlines. Its not as easy as it is to type it on your resume. It actually means something.

What is a deadline, really? Well, according to the Wiktionary:

deadline (plural deadlines)

A date on or before which something must be completed.

I must make this deadline or my boss will kill me!
(archaic) A guideline marked on a plate for a printing press.
(archaic) A line which doesn’t move.
(archaic) A boundary around a prison

The connotation around number 4 could prove to be a bit extreme etymologically speaking, but what does this definition tell us? Probably nothing we didn’t already know. Its a date. A date by when something is due by. Not hard, right? I pay by bills by a date, I get my car’s oil changed by a date, I go to the dentist by a date. Easy peasy.

Not so much. A deadline means so much more than how its defined. As a matter of fact, weare often the ones defining the deadlines. We define the deliverables. We define the dates. Its so much more than doing something by a date, its defining what needs done by when.

Need to ask ourselves about our deadline, to help define it for our circumstance:

What are some risk mitigation strategies for your deadlines?
Where does your deadline get communicated?
How to do you state your deadline?
How soft or hard is this deadline?
What is going to impact this deadline?
Is this deadline clear, or clear as mud?
What is expected at the end of the deadline?
How do you estimate your deadline?
When should you ask advice before giving your deadline?
When should escalate a concern about your deadline?

Communicating and escalating risks earlier is also a key component to meeting and estimating deadlines consistently.

Here is what NOT to do:

Provide a deadline in this format “I’ll have that to you sometime on Friday”;
Jump on the first distracting or more fun project thrown in front of you – any chance to do something else
Let scope creep out and destroy your project plan as that hard earned feedback rolls in;
Wait to escalate a problem until after you’ve run out of time

Here is what you could do:

Provide specific dates, and times
Communicate multiple dates – be as transparent as you can be; what is the ideal/ best case scenario? What is more likely to be delivery date? What is the worst case scenario? Express your concerns immediately.
Communicate as soon as you are aware of what will impact that will have on your plan to meet your estimated deadline
If you are unsure, ask for time to think about it, and get back with your estimate later
Include a confidence rating on how confident you are that deadline is likely to be met
Don’t be easily distracted from your original plan – escalate the question to someone who can see the bigger picture, your manager or director
“Communicating early” does not mean to wait to communicate when the deadline is slipping, it means to communicate as soon as you’ve identified something that may cause it to slip.
When the impact of an unplanned activity has equal priority, escalate the decision immediately. Don’t think you can make that call with out being the tiniest bit subjective – when we’re that close the project, we’re often too close to make the best call for the company.

It takes time to systematically approach a problem until its second nature. Thinking of deadlines, feedback and scope creep in terms of requirements feels more systematic, more error-proof, and more organized.

Good luck, and happy self-analyzing!

ISO 25010

Adriano Comai — Fri, 20 Jan 2012 09:36:00 GMT

ISO 25010, "Systems and software engineering - System and software quality models" was published in March 2011.

The ISO 25010 standard defines 2 broad non-functional categories of requirements, "Quality in use" and "Product quality", articulated in 13 characteristics, many of which are further subdivided into sub-characteristics. This new standard replaces the previous ISO 9126 standard, heavily used both in requirements management and in testing.

To find out more, see my pdf presentation.

Requirements Gathering

a.prvz — Wed, 08 Jun 2011 09:49:00 GMT

Requirements gathering is an essential part of any project and project management. Understanding fully what a project will deliver is critical to its success. This may sound like common sense, but surprisingly it's an area that is often given far too little attention.

Many projects start with the barest headline list of requirements, only to find later the customers' needs have not been properly understood.

One-way to avoid this problem is by producing a statement of requirements. This document is a guide to the main requirements of the project. It provides:

A succinct requirement specification for management purposes.
A statement of key objectives - a "cardinal points" specification.
A description of the environment in which the system will work.
Background information and references to other relevant material.
Information on major design constraints.

The contents of the statement of requirements should be stable or change relatively slowly.

Once you have created your statement of requirements, ensure the customer and all other stakeholders sign-up to it and understand that this and only this will be delivered.

Finally, ensure you have cross-referenced the requirements in the statement of requirements with those in the project definition report to ensure there is no mismatch.

10 Rules for Successful Requirements Gathering

To be successful at requirements gathering and to give your project an increased likelihood of success follow these rules:

Don't assume you know what the customer wants, ask.
Involve the users from the start.
Define and agree the scope of the project.
Ensure requirements are specific, realistic and measurable.
Gain clarity if there is any doubt.
Create a clear, concise and thorough requirements document and share it with the customer.
Confirm your understanding of the requirements with the customer (play them back).
Avoid talking technology or solutions until the requirements are fully understood.
Get the requirements agreed with the stakeholders before the project starts.
Create a prototype if necessary to confirm or refine the customers' requirements.

Common Mistakes

Basing a solution on complex or cutting edge technology and then discovering that it cannot easily be rolled out to the 'real world'.
Not prioritising the User Requirements, for example 'must have', 'should have', 'could have' and 'would have,' known as the MoSCoW principle.
Not enough consultation with real users and practitioners.
Solving the 'problem' before you know what it is.
Lacking a clear understanding and making assumptions rather than asking.

Requirements gathering is about creating a clear, concise and agreed set of customer requirements that allow you to provide exactly what they are looking for.

Is Traceability Possible Without a Requirements Tool?

Seilevel — Mon, 20 Dec 2010 05:07:00 GMT

I have spent the last year and a half working on an enterprise software solution development effort where we do not use a Requirements Management tool like Caliber or Visual Studio TFS. Our requirements are created in Word using standardized templates and distributed to Development and Test teams for consumption.

Test cases are written in Excel and tied to the requirements in the documents. In general, I would have to say that coverage is good but not complete (I know this anecdotally since there is no good way using Excel and a bunch of Word documents to know for certain). In theory, a failed test case should mean that a requirement is not satisfied and pinpoints a missed feature or requirement.

This system breaks down totally when it comes to Change Requests that are created during the course of the project. Change Requests are entered directly into a defect tracking system. Change Requests are usually supposed to have detailed requirements associated with them but in practice the quality of the supporting documentation has varied widely. So, Change Requests have little to no systematic traceability associated with them. This is not to imply that the Change Requests are poorly implemented. Just that doing any kind of systematic tracing exercise against them is near impossible.

The key problems I have found with using Excel to perform traceability are as follows.

1. Forward traceability from Business Objectives or High Level Features to specific requirements is very difficult to do and in many cases is just not practical.
2. Managing requirements as they change is very difficult to do. You could have false positives where the spreadsheet tells you there is good coverage without realizing that the underlying requirement itself has changed.
3. Managing multiple tests for a single requirement because very difficult. For example, if a single requirement has to pass 3 test cases for it to be considered fully implemented, the spreadsheet approach becomes error prone and hard to understand very quickly.
4. The spreadsheets themselves become unwieldy as multiple requirements and tests are entered. The volume of data becomes hard to manage and consume.
5. Reporting becomes a hit and miss process. It requires a lot of manual effort, is time consuming and error prone.
6. Requirements that do not start life in a requirements document (Change Requests) are seldom tracked as rigorously as standard requirements.
7. Historical analysis is very difficult to do. On projects that last several years, digging up an old Excel spreadsheet to determine if specific requirements were implemented or not a year ago can easily become a week long exercise in futility.

So what then is the answer to the question I posed at the beginning?

Excel is fine for small projects but larger enterprise grade efforts require a specialized requirements tool with good tracing features.

The odds of performing good traceability on your project are significantly improved when using a requirements management tool. There are real costs associated with unimplemented or improperly implemented requirements. A good tool gives you a better chance of catching these kinds of errors with good traceability features. So, when considering a tool to manage your requirements, do not overlook the quality of their traceability features.

For more check out our blog: http://requirements.seilevel.com/blog/

By Abadri

Square pegs, round holes - why non-funcs are really not stories

FergalMcGovern — Fri, 17 Dec 2010 21:11:00 GMT

I've been blogging lately about a couple of topics pertaining to 'agile' methods. Along those lines, I wanted to consider one suggested practice that I think is worth reflecting on, that is; the treatment of NFRs (non-functional requirements) as stories.

Let's draw back for a moment. Regardless of process approach, be it traditional or agile, poor treatment of NFRs is one of the highest risk areas in IT delivery. For anyone who has been involved in even a half-way serious type of project, lack of adequate NFR consideration will royally bite you in the bum. In my experience, it is probably the single biggest cause of lost sleep, likely I suspect accounting for the highest rate of ulcers for project & program managers. This applies to stakeholders at all levels, from project managers to executives. Executives as they realise in horror that the $70 million integration project due to go into production in 2 months time is behind and is not scaling according to plan and the business is looking for a release date or that the production system is down periodically for long spells due to scaling issues.

Many stressful roads lead back to NFRs and if the NFR horse has bolted on your project, get ready for some serious stress. That said, let me get back to the point of this post, NFRs as stories.

So, I'd like to challenge one of the sacred cows for some in the agile community; namely that 'everything is a story', including NFRs.

A number of blog posts argue for representing NFRs as stories, including this one. Not everyone in the agile community agrees. The excellent Scott Selhurst blog is a notable example of extremely balanced thinking in that regard. Tom and kai Gilb have a lot to say on the matter here irrespective of whether you're in traditional or agile settings or a mix.

Let's get a definition or two out there, so we're on the same page. Firstly what is an NFR? I will take the definition I first spotted in the 'HP Fusion' process oh about 18 or so years ago, that is we have basically two types of NFRs; Qualities and Constraints. Qualities are generally very clearly measurable and represent things like performance, uptime, data load etc, the classic 'ilities'. Qualities will tend to be associated with strands of functionality or with the system as a whole. Constraints tend to be exactly that, statements of constraint, for instance 'we must support IE 6' (at VisibleThread this particular one pains me considering the variations on service pack OS etc. but as we do have customers on IE 6 we need to satisfy this constraint). An example of a second constraint is: 'Must have a legal disclaimer on every page of the web interface' or 'we must code in Java on JDK version x.y'

You may not agree with the qualities or constraint delineation or have differing views but that's fine, work with me, whatever you choose to call them, most people agree that both styles of NFR exist, regardless of your definition or terminology.

Let me offer a few reasons for why agile analysts & team members should consider avoiding representing NFRs as stories.

Communication: NFRs often have a heavier impact than stories on core design foundations. Ask any tech architect or design lead for war stories on challenged projects they know and you are highly likely to be able to attribute the issue to lack of ability to satisfy one or more NFR as it's root cause. Therefore the act of calling out NFRs as something that is not a story is of immense value from a communication standpoint. As an architect seeing a clear delineation of NFRs (particularly the qualities) from stories helps identify incompleteness.
Cross-cutting scope: NFRs tend to come in two broad 'namespaces', those that apply universally across the project and those that may be associated with 1 or more strands of functionality, (a story in Agile-land). Handling both types of NFRs as stories does not easily allow us to map 1 NFR to multiple stories
Elicitation: NFRs are by their nature, the most difficult class of requirements to elicit. Having explicit categorization and expectation that not only will they exist, but that they are measurable and verifiable forces serious questions to be addressed upfront in iteration-0. By forcing a clarification of measures early in the process around NFRs such as security or scalability, key design and architecture inputs may adjust trajectory
Quality type NFRs are assertions with properties: NFRs are not functional in nature, stories are a functional artifact. Whilst it can be a useful device to use a story persona as a way to drive elicitation of NFRs, in normal complex systems where you need to put in multiple additional associated attributes; boundary values, max, min, mean, load etc., a tabular format tends to be more comfortable for people to read & document.
Testing: Having 1 NFR, particularly Quality oriented NFRs, represented in tabular fashion with each row outlining testable measures for instance, leads to a better ability to conduct test planning. It also means that we can incrementally knock off specific rows as part of particular sprints, yet have the more general NFR in place so it's pervasive and front of mind. Even the best intentioned team members may forget the NFR obligation unless it's kept front of mind.
NFR Lifecycle: Non-trivial NFRs in many cases can affect multiple sprints and have a life-cycle that lasts far longer than a 2 week sprint. Artificially closing them and re-opening them to suit sprint management is not following a principle I try to stick with, that of 'common sense'.

Finally, the agile manifesto really says nothing about NFRs having to be represented as stories. That particular idea is really a vestige of specific agile methods. The true spirit of agile is as much about common sense and 'fit for purpose' as anything else. So, don't be too afraid to stand up and say no to NFRs as stories.

Of course, if you find that NFRs as stories work for your context, excellent. It's just that in my experience, it's really pushing a square peg into a round hole, when we could just as easily fit a square peg into a square hole!

Learned Processes

Seilevel — Tue, 26 Oct 2010 18:59:00 GMT

I know you are going to call me crazy, but I just have to let everyone know. Machines are controlling us. Don’t say I didn’t warn you. You don’t believe me? Okay, I’ll explain.

People come and go in organizations. Systems tend to stay much longer. Simple enough right? Here is the kicker. When that system was implemented, it was implemented to solve a problem. But it did not have all the capabilities required to solve all the problems the business had. So in order to fix the big problem, lots of little problems sprung up.

They weren’t an issue of course because the business had workarounds, usually manual ones. No biggie right? Well, maybe.

Let us say it is five years later and the original people who worked with the system are gone. The replacements were only trained on how to follow the process and not why the processes should be followed. There is the start; the machine has people doing its bidding.

Then a few years later it is decided that some systems should be replaced. So when all of the requirements analysts come in to do their thing, they document the process as is from the users and SMEs. This then gets propagated to the new systems. And thus, the old system lives on through the new system. The old bugs are now required functionality.

We must stop them! When working with old systems and processes don’t just ask what the current state of affairs is. Be sure to ask why it is done the way it is. This was happening on one of my previous projects. The inabilities of the old system were being written into requirements for the new system. Unnecessary needs for manual selections and processes were being maintained.

The project was so large and unruly that other requirements analysts would simply write down the current process and confirm it is how things work. This practice caused very complicated user interactions during the sales process and contract creation. After the fact, people realized that they should have automated more and asked the user questions about what to do less.

Because the software being implemented did not come with all this added functionality, it ended up costing the company much more money to reevaluate what was really needed, what could be covered by alternative existing features, and what would just go unimplemented.

By JHEEP

Want other software requirements posts? http://requirements.seilevel.com/blog/

The single most important failure with requirements

Seilevel — Thu, 23 Sep 2010 00:59:00 GMT

A lot of our clients bring us in to fix their requirements issues. Based on the literature a lot of what you see about requirements is geared towards making sure that you write a requirement in the correct way – measurable, testable, traceable and atomic. Our experience with many Fortune 500 companies leads to a different issue being the most important issue, one that seems easy to solve, but is actually incredibly difficult to solve.

Ultimately software projects get chartered because an executive decided that it was worth spending the money. This should be related to a corporate strategy in some way, but usually is not. The breakdown and the ensuing issues almost always occur at this level.

The single most important failure with requirements occurs when executives charter a project without a measurable business outcome.

This sounds like an absurdly simple problem to solve, but I assure you it is not. For a variety of reasons, executives chartering software projects are adept at avoiding any sort of accountability for results. What makes the problem extraordinarily hard to solve is that it requires the leaders in the company, the CXOs, to demand that business results be identified from every program. Surprisingly this doesn’t happen very often.

The lack of clarity around measureable business objectives drives a lack of clarity to the entire rest of the project. This doesn’t mean that all projects will fail – often times project teams deliver a reasonable quality product that does generally the right things. These cases are when the issues are so completely obvious that it is virtually impossible for anyone to get it wrong. But more often people on the project invent many different reasons for why a project exists.

This single issue can result in a myriad of project problems. The issue manifests in many different ways including:

1) Projects go massively over budget because of scope creep

Scope creep is extremely easy to solve if you know what you are trying to achieve. Typically scope creep is introduced for areas that have nothing to do with the core purpose of the project. The ideas will always be good ideas, just not key to the measurable value of the project. On one project we worked on, the value was a $20M one time gain with a $20M yearly gain. The project cost was $2-3M. The stakeholder team (developers, project managers and business users) consistently wanted to add features that made the business users’ jobs more streamlined. The software would already increase their productivity, but not as much as they wanted. Because of a focus on the return (unrelated to productivity), we were able to keep the scope creep out of the release and deploy much sooner.

However on another project, the executives refuse to assign business objectives to the project and the business users keep asking for additional features that are “critical”. When we evaluated the return on the features, the return is literally almost zero and the cost is in the high 6 figures. This project is extraordinarily late and has no clear direction.

2) Projects are constantly short of resources because too many projects are being worked on

One organization we work with consistently charters too many projects. The money is there, but the resources simply are not. This means that many projects get started but then stall or are poorly deployed because key resources, including developers who know the ecosystem are simply overworked. We started on a project once that had a $4M yearly return. This was not bad, except that there was another project that had a $100M yearly return. We recommended to our stakeholders that they cancel our project and move the entire team over to the more valuable project. They chose not to and neither project has significantly deployed (6 months late). Under resourcing all projects by a little (or a lot) results in no projects being deployed well. A better strategy would be to identify the top projects by business objectives and resource them adequately. The I want it all strategy is doomed to fail.

3) Projects get canceled due to lack of interest

Projects often get chartered due to the charisma of a single stakeholder, but because there isn’t any business value they often eventually run out of steam. This actually is a better result than a project that keeps trying to deploy because canceling the project saves a lot of money. This could be avoided in the first place by proper portfolio management based on measurable business objectives.

4) Projects deliver but don’t get used by the users

This is a difficult one. We see this happen quite often and depending on the environment it may or may not be a problem. In one of the examples above, the users didn’t want to use the software because it wasn’t as easy to use as they would have liked. Yet the company could immediately get a lot of value from it. In this case it was worth it to deploy the software because the value was there and when it was explained to the users they were willing to take a usability hit to get the value. I feel bad for the users because they are the ones to suffer from these types of decisions. However I do believe that the organization is committed to successive releases that will improve usability and the cost of those is incorporated into the overall ROI . In cases where the business does not support the value the software simply does not get used. I have seen sales VPs tell the CEO that if their teams are forced to use a particular release of software that they can’t hit their very public revenue targets. This game of chicken can be avoided by making sure there is agreement at the executive level of the value of the software.

If your organization has a culture of accountability then you might already be doing these things. Our experience is that most companies have a lack of accountability for measurable business results when it comes to deploying software. As a lowly BA or IT product manager you aren’t going to be able to change the business objectives or corporate strategy, but in our experience you can make sure you understand them and even rewrite them for your team in a measurable way. This requires you to step up and choose to be held accountable. If you are able to do this and can achieve results, I assure you this is the best way to get on the career fast track.

Are you up to the challenge?

http://www.seilevel.com/

Requirements Engineering Conference Is Just Around The Corner

Seilevel — Tue, 07 Sep 2010 00:06:00 GMT

Its being held in Sydney Australia September 27th- October 1st 2010.If you are attending this conference don’t miss out on the Requirements Engineering Education and Training Workshop that is taking place September 28th.

Do you want to broaden your skills? Learn new techniques? This is the workshop for you.

This workshop will address issues related to Requirements Engineering education, both as part of a formal university degree and as ongoing skills training within the workplace. The workshop is intended to go much deeper than a surface discussion of curriculum issues and will examine specific ideas and techniques for teaching and assessing skills needed by an effective requirements engineer.

Curriculum design

Curriculum for undergraduate and graduate level RE studies
Mapping RE elements from the SWEBOK (Software Engineering Body Of Knowledge) to RE curricula
Identifying and incorporating specific RE related topics into the general curriculum and/or software engineering courses
Curriculum for industrial training programs

Techniques for teaching specific RE related skills

Creative methods for teaching stakeholder identification, requirements elicitation, negotiation and consensus building, requirements writing, and other critical RE skills
Specific tools, exercises, and assignments developed to support RE skills training

Assessment methods and practices of RE knowledge and skills

Which assessment method to use: exam, test, case study, essay, report, presentation, or something else?
Strategies for assessment of learning soft skills
What should students be able to do as a result of learning RE?
Methods of objectively measuring assessments

Effective pedagogical methods for teaching RE skills

Survey results related to topics such as the effectiveness of teaching methods, RE skills needed to be effective in industry, skill mismatches between graduating students and industry needs etc.
Studies into the effectiveness of requirements engineering educational practices
Experience reports including industrial training and university level curriculum

Do you want more information?

http://www.re10.org

http://users.cscs.wmin.ac.uk/REET10/Overview.html

Blurring the Lines between Business and IT

Derek Roos — Thu, 21 Jan 2010 10:51:00 GMT

A “What If” question for business analysts and IT professionals…

What if it suddenly became very easy for someone to do both your job and their own, at the same time? If history provides any forecast for the future of IT, we are likely to see some interesting changes in the way human capital is managed – especially for those of us involved in the emergence of cloud computing. Clouds push complexity to the background and allow users to focus on what really matters: functionality and costs.

Have you ever noticed how the education we receive often sets boundaries in our career aspirations? We are trained to do something, and do it well – but in doing so, we take for granted the fact that others are doing the same thing in a different field. Then, when we are faced with an inevitable change, we instinctively take a “That’s not what I’ve been trained to do, there are other people for that” mentality. Sure, there are the motivated few who push down boundaries and become renaissance men and women in their own right. But when everyone else is set in their ways, these people are often considered a risk… think: too many eggs in one basket.

Now, to regress from my pseudo-philosophical banter, this trend is becoming all the more apparent as business analysts become more involved in technical training. Most IT veterans would say that business analysts will never have the true know-how to implement their plans, requirements and recommendations. The modern business analyst usually considers themselves more of a problem solver than a programmer – hence the separation of labor in this function of any business. Having surveyed the blogosphere for opinions of business analysts and IT professionals, there seems to be a live (and even a bit emotional) discussion between those who say it is a natural, and therefore inevitable, progression and those who say it is a “pie in the sky” and that it will never happen.

Contrastingly, a growing population of believers has something to say about the segregation of business and IT. In a world of zeros and ones, the innumerable coding languages can only become more and more efficient. As coding languages are continuously created, survival of the fittest can account for the extinct languages of modern programming. An abstraction of these languages is an ongoing phenomenon with a light at the end of the tunnel. Some say that using abstract, visual and human-readable models instead of low-level code is a very important step towards commoditized coding.

I’ve come to think about this abstraction phenomenon as measure to increase efficiency. When our ancestors realized that making bricks was faster than packing sand, they were on to something similar. If someone else uses molds to make perfectly shaped bricks that can be built into any structure, the workers need different skills but can ultimately build more economically, the architect can plan more accurately, and the buyer can move in earlier. So, why deal with sand when we can get the bricks from vendors elsewhere. Why deal with code, when we can get software modules elsewhere? This, my friends, may be the future of today’s business analyst. In the future, what if business analysts had the skill set and the molds to create bricks that satisfy their requirements without the need to deal with code – or sand?

Derek Roos
CEO
www.mendix.com

Abandon the use of Non Functional Requirements

Craig Brown — Thu, 24 Sep 2009 11:57:00 GMT

This model is provided by Don Firesmith of SEI. Note the lack of an NFR category.

Presenting Reporting Requirements in a BRD

stobin — Tue, 04 Aug 2009 17:49:00 GMT

We have been struggling with what to include in a Business Requirements Document concerning reports. Because our BRD is more or less a contract between the client and our IT department, the greater the detail in this document the longer the time to obtain signoff. There are always modifications that are deemed necessary before signoff can happen. Often these modifications have technical impacts on design and development. I'm looking for suggestions on what to include and what not to include in the Reports section of the BRD. Comments are welcome.

Our current document includes the following:

7.1.1 Report Name

7.1.1.1 Description

7.1.1.2 Frequency

7.1.1.3 Selection Criteria (parameters used to select data for inclusion in the report)

7.1.1.4 Fields

7.1.1.5 Sort Order

7.1.1.6 Extraordinary Calculations

Help your stakeholders review your requirements

Craig Brown — Fri, 13 Feb 2009 10:58:00 GMT

Writing requirements

Craig Brown — Fri, 09 Jan 2009 12:14:00 GMT

Requirement Writing for Product Management

Carnival of Business Analysts #5 - Requirements Analysis

Craig Brown — Sun, 16 Dec 2007 18:22:00 GMT

The 5^th edition of the Carnival of Business Analysts has been published at Better Projects. This edition is focused on Requirements Analysis.

This is a series of blog posts that collect other blog posts on topics themed around the BABOK knowledge areas. Edition 5 is on Requirements Analysis.

Previous editions include Looking at the role of the BA, the BA and Quality, Requirements Planning and Requirements elicitation.

Read it here.